Re^16: Страуструп о будущем семантических средств разработки с комментариями

>>Ты их всё равно из базы берёшь. Зачем(!) ты их в памяти складируешь, когда их можно обработать сразу?

> Что будет быстрее: взять один раз N записей из базы или сделать M запросов по K записей (где N=M*K)? (При условии, что некоторые СУБД при выполнении select-а из таблицы блокируют операции записи в нее).

Курсорами пользоваться не умеем, да?

>>Можешь брать из базы по n штук за раз и запускать n потоков.

> И какое же тогда будет n? :)

Ну это уже протестируй и выбери. Пусть будет для начала 22.

>>>Из БД поднимается 15K записей об изменении состояния счетов абонентов. По этим записям строятся сообщения которые абоненты должны получить, например, в виде SMS или e-mail.

>> Почему бы по мере выфетчивания из курсора это не делать?

>Вот до чего доводит людей ORM %)

Так и пишутся С++ бэкэнды которые тормознее жабских фронтэндов. Простой такой жабский серверок на nio/reactor design pattern с пятью тредами опускал плюсовый биллинг в глубокий даун - он зверски жрал пямять и порождал по некольку тредов на каждый запрос. Пришлось троттлер делать.

>Курсорами пользоваться не умеем, да?

Конечно нет.

>Ну это уже протестируй и выбери. Пусть будет для начала 22.

Ну ты сам протестируй, во что будет обходиться старт и джоин 22-х потоков.

Re^18: Страуструп о будущем семантических средств разработки с комментариями

>>Курсорами пользоваться не умеем, да?

> Конечно нет.

Учись, в жизни пригодится. Как ты, например, жену из роддома без курсора забирать будешь!?

>>Ну это уже протестируй и выбери. Пусть будет для начала 22.

> Ну ты сам протестируй, во что будет обходиться старт и джоин 22-х потоков.

Ну ты же сам хотел распараллелить, а теперь возмущаешься, что не подходит. Будь последователен.

http://mina.apache.org/features.html

Overload shielding & traffic throttling

Ну и зачем делать троттлер, если он уже встроен в жабу?

>http://mina.apache.org/features.html

>Overload shielding & traffic throttling

Давай ищо жабские фреймворки в этом топике обсудим.

>> Предлагаете после каждого прохода по массиву из 10 элементов собирать треды у барьера?

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

Почему бы fork & exec("gpg ...") не сделать?. Что-то не верю я в такие эпизодические разбросанные по проекту оптимизации. Многопоточность эффективна для каких-то взаимно малозависимых расчетов типа одно ядро рендерит четные кадры, а другое-нечетные. Или одно ядро удаляет из сцены заведомо невидимые объекты а другое рендерит оставшиеся.

>> Пример полезности таких коллекций из девелоперской практики будет? И насколько серьезную трансформацию намерены применить?

>Ну хоть поиск фундаментальных циклов огромного графа с кучей компонент связности.

С помощью for_each?

ЛОЛ жесть клоун заюзал буст и называет это "поддержкой ФП на уровне языка". Гасите свет...

> ЛОЛ жесть клоун заюзал буст и называет это "поддержкой ФП на уровне языка". Гасите свет...

Ты больной дуралей и спорить с тобой бестолку. Он ответил на твой вопрос про фунарг, про ФП ни слова не сказал.

Re^14: Страуструп о будущем семантических средств разработки с комментариями

>>> Пример полезности таких коллекций из девелоперской практики будет? И насколько серьезную трансформацию намерены применить?

>>Ну хоть поиск фундаментальных циклов огромного графа с кучей компонент связности.

> С помощью for_each?

Там надо пройтись по всем вершинам, почему бы это не оформить как for_each, а не писать длинный for с итераторами?

>Почему бы fork & exec("gpg ...") не сделать?.

Почему бы не сравнить скорость fork+exec со скоростью beginthread+работу библиотечного кода?

Почему бы не проверить кроссплатформенность fork+exec?

> Что-то не верю я в такие эпизодические разбросанные по проекту оптимизации.

Что-то ты не веришь в то, что на C++ можно писать просто, быстро и эффективно.

> Многопоточность эффективна для каких-то взаимно малозависимых расчетов типа одно ядро рендерит четные кадры, а другое-нечетные. Или одно ядро удаляет из сцены заведомо невидимые объекты а другое рендерит оставшиеся.

Многопоточность много для чего эффективна и много для чего неэффективна. Но это не значит, что в parallel_for_each не будет необходимости. И не значит, что тупой for будет проще распараллелить, чем заменить std::for_each на std::parallel_for_each.

>>Почему бы fork & exec("gpg ...") не сделать?.

>Почему бы не сравнить скорость fork+exec со скоростью beginthread+работу библиотечного кода?

fork+exec 2 my mind будет несоизмерим со временем работы gpg если документы действительно большие. Кроме того, не хочется исследовать использование глобальных переменных библиотечным кодом в многопоточной среде. И давать свою кучу библиотечному коду тоже не хочется.

>Почему бы не проверить кроссплатформенность fork+exec?

Этот вопрос задается на ЛОР?

>> Многопоточность эффективна для каких-то взаимно малозависимых расчетов типа одно ядро рендерит четные кадры, а другое-нечетные. Или одно ядро удаляет из сцены заведомо невидимые объекты а другое рендерит оставшиеся.

>Многопоточность много для чего эффективна и много для чего неэффективна. Но это не значит, что в parallel_for_each не будет необходимости. И не значит, что тупой for будет проще распараллелить, чем заменить std::for_each на std::parallel_for_each.

Почему бы не сделать какую-то вьюшку (т.н lazy eval) для тех данных которые предполагается трансформировать с помошью std::for_each? Вряд ли все данные нужны сразу.

>>>> Пример полезности таких коллекций из девелоперской практики будет? И насколько серьезную трансформацию намерены применить?

>>>Ну хоть поиск фундаментальных циклов огромного графа с кучей компонент связности.

>> С помощью for_each?

>Там надо пройтись по всем вершинам, почему бы это не оформить как for_each, а не писать длинный for с итераторами?

Какие-то промежуточные результаты использоваться не будут? Параллельный вариант for_each будет ведь обходить элементы не по порядку.

>Ты больной дуралей и спорить с тобой бестолку. Он ответил на твой вопрос про фунарг, про ФП ни слова не сказал.

Ты дибил или просто слепой? Понимаешь, что такое "поддержка на уровне языка" и чем это отличается от "реализации с помощью средств метапрограммирования языка"?

Ну ты точно больной. Перечитай свой вопрос и ответы на него.

У тебя дислексия.

Занимайся метанопрограммированием в другом месте )

>> ЛОЛ жесть клоун заюзал буст и называет это "поддержкой ФП на уровне языка". Гасите свет...

>Ты больной дуралей и спорить с тобой бестолку. Он ответил на твой вопрос про фунарг, про ФП ни слова не сказал.

Вся эта шаблонная муть настолько хрупка, что даже практичные сторонники плюсов в этом топике постремились дистанцироваться или занять выжидательную позицию пока лямбды и концепты не вошли в основную ветку gcc. И что за тип такой - long(long)? Очевидно это тип так как он в шаблонном параметре обозначен как "typename Signature". Я знаю сигнатуры вида long(*)(long), но оно там не прокатывает и диагностика этого не читается. Еще этот хэлловорлд компилируется сравнительно долго на 3GHz машине, так что плач Строуструпа по поводу тормозного линкера для Simula можно считать эпическим фэйлом.

Re^16: Страуструп о будущем семантических средств разработки с комментариями

>>Там надо пройтись по всем вершинам, почему бы это не оформить как for_each, а не писать длинный for с итераторами?

> Какие-то промежуточные результаты использоваться не будут? Параллельный вариант for_each будет ведь обходить элементы не по порядку.

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

>fork+exec 2 my mind будет несоизмерим со временем работы gpg если документы действительно большие.

Типично Java-вский подход: здесь 5ms не важно, там 20ms -- мелочь, GC на 100ms приложение притормозит -- не беда все это.

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

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

Параноя.

>>Почему бы не проверить кроссплатформенность fork+exec?

>Этот вопрос задается на ЛОР?

Религия ЛОР-а запрещает писать кроссплатформенный код?

>Почему бы не сделать какую-то вьюшку (т.н lazy eval) для тех данных которые предполагается трансформировать с помошью std::for_each? Вряд ли все данные нужны сразу.

Ну сделай вьюшку для поиска минимума/максимума в последовательности чисел. Или для умножения этой же последовательности на некоторый коэффициент. Параллельные версии std::for_each здесь будут гораздо больше в тему, чем for-циклы или lazy eval-ы.

> Ну я же говорю: интуиция. Если использовано нечто, имеющее зарезервированное имя, то это указывает на некоторую кривость реализации. В сорсы смотреть лень, но там, наверно, эти _1, _2 и т.д. генерируются каким-нибудь несвойственным для языка способом. А это может повлечь за собой то, что с такой _переменной я не смогу работать как с обычной переменной.

Интуиция тебе подвела. Ты можешь сам объявить свойственным для языка способом например X Y Z, и они будут так же работать, как и _1 _2 _3.

Но переменная это правда не совсем обычная -- и в этом замысел.

> ЛОЛ жесть клоун заюзал буст и называет это "поддержкой ФП на уровне языка". Гасите свет...

Я не называл это поддержкой ФП на уровне языка. И еще:

поддержка ФП библиотеками лучше, чем поддержка ФП на уровне языка.

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

>>fork+exec 2 my mind будет несоизмерим со временем работы gpg если документы действительно большие.

>Типично Java-вский подход: здесь 5ms не важно, там 20ms -- мелочь, GC на 100ms приложение притормозит -- не беда все это.

А С++ подход - это клепать комбайны "все в одном"? Я знал я знал. На Pentium-133 AFAIK было по 300 форков в секунду. А нам всего надо подсчитать электронные подписи для 10 документов.

>Не говоря уже про то, что нужно организовывать ожидание внешних процессов, контроль их ошибок

Это в общем несложно ведь у нас такой глобальный и надежный язык как С++.

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

>Параноя.

Отнюдь нет. Линукс более устойчив чем оффтопег отчасти поскольку в нем не принято делать огромные комбайны с кучей in-proc COM компонентов и тредов.

>включать в состав приложения внешние инструменты и пр.

Есть такое понятие как "зависимости"

>Особенно все это весело, если документ находится в памяти моего процесса (например, XML для подписи).

man 2 pipe

>>>Почему бы не проверить кроссплатформенность fork+exec?

>>Этот вопрос задается на ЛОР?

>Религия ЛОР-а запрещает писать кроссплатформенный код?

Ну хорошо, fork+exec в оффтопике придется заменить на CreateProcess()

>>Почему бы не сделать какую-то вьюшку (т.н lazy eval) для тех данных которые предполагается трансформировать с помошью std::for_each? Вряд ли все данные нужны сразу.

>Ну сделай вьюшку для поиска минимума/максимума в последовательности чисел.

В 15K элементов? А правильная ли структура данных выбрана?

>Или для умножения этой же последовательности на некоторый коэффициент.

А почему бы векторные комманды CPU не использовать?

> но оно там не прокатывает и диагностика этого не читается

У плюсов ужасные 1) синтаксис 2) диагностика 3) скорость компиляции (по крайней мере у gcc)

0x может поправить п.2, остальные видимо останутся.

>> Или для умножения этой же последовательности на некоторый коэффициент.

> А почему бы векторные комманды CPU не использовать?

А почему бы не использовать векторные команды сразу нескольких CPU? %)

>>> Или для умножения этой же последовательности на некоторый коэффициент.

>> А почему бы векторные комманды CPU не использовать?

>А почему бы не использовать векторные команды сразу нескольких CPU? %)

А синхронизация не сожрет больше ресурсов, чем мы какбе надеемся выиграть? Божественный Счетчик Ссылок в смарт-указателях будет захватывать мутекс (InterlockedIncrement для юзерспейса в линукс нет). COW в многопоточной среде работать не будет. Не верю я в такие эпизодические припарки - программу надо изначально проектировать под многотредовость и раздавать тредам куски работы покрупнее.

> Божественный Счетчик Ссылок в смарт-указателях будет захватывать мутекс (InterlockedIncrement для юзерспейса в линукс нет).

Счетчик ссылок никто и пиарил хотя бы в 1/100 от пиара Божественной Явы.

А по сути --

1. Минимизировать надо все эти общие объекты, лучше пусть имеют конкретного владельца

2. Плюсам нужен хороший GC, но не для всех классов, как в Д, а только как боксинг в случаях, где компилятор сочтет это необходимым.

> InterlockedIncrement для юзерспейса в линукс нет

Был atomic_inc(atomic_t *) и atomic_dec_and_test(atomic_t *)

( http://ozlabs.org/pipermail/linuxppc-dev/2002-January/012997.html )

Re^6: Страуструп о будущем семантических средств разработки с комментариями

>> Ну я же говорю: интуиция. Если использовано нечто, имеющее зарезервированное имя, то это указывает на некоторую кривость реализации. В сорсы смотреть лень, но там, наверно, эти _1, _2 и т.д. генерируются каким-нибудь несвойственным для языка способом. А это может повлечь за собой то, что с такой _переменной я не смогу работать как с обычной переменной.

> Интуиция тебе подвела. Ты можешь сам объявить свойственным для языка способом например X Y Z, и они будут так же работать, как и _1 _2 _3.

Ну и что, я могу от этих _1 взять адрес? А могу я их объявить ссылками? А константными ссылками?

> Но переменная это правда не совсем обычная -- и в этом замысел.

Не нравятся моей интуиции такие замыслы :)

>А С++ подход - это клепать комбайны "все в одном"? Я знал я знал.

Еще бы ты не знал -- ты же переносишь свой собственный способ мышления на весь мир.

>На Pentium-133 AFAIK было по 300 форков в секунду.

А сейчас?

>А нам всего надо подсчитать электронные подписи для 10 документов.

10 документов -- это всего лишь маленькая часть. Но мы ее обернем кучей fork-ов и внешних утилит, напишем всю эту байду исключительно на C и исключительно под Linux. Это настоящий Ъ.

>>Не говоря уже про то, что нужно организовывать ожидание внешних процессов, контроль их ошибок

>Это в общем несложно ведь у нас такой глобальный и надежный язык как С++.

Т.е. на Java ничего этого делать не нужно, правда?

>>Параноя.

>Отнюдь нет. Линукс более устойчив чем оффтопег отчасти поскольку в нем не принято делать огромные комбайны с кучей in-proc COM компонентов и тредов.

Linux временами производит впечатление более устойчивого, но лишь за счет того, что под него программирует в несколько тысяч раз меньше ламеров, чем под оффтопик.

>>Религия ЛОР-а запрещает писать кроссплатформенный код?

>Ну хорошо, fork+exec в оффтопике придется заменить на CreateProcess()

А теперь сам подумай: что проще -- иметь один код по запуску нескольких нитей (который практически не будет меняться на большинстве платформ) или возиться с fork/exec/CreateProcess+вся прелесь по организации pipe/files? И добавь сюда накладные расходы.

>>Ну сделай вьюшку для поиска минимума/максимума в последовательности чисел.

>В 15K элементов? А правильная ли структура данных выбрана?

А какие ты структуры данных знаешь правильные? Например, для хранения 15K "сырых" результатов замеров (скажем, со счетчика энергопотребления, или расхода воды, или даже ускорителей (ты представляешь, какими объемами оперировали в BaBar-проекте?)).

>>Или для умножения этой же последовательности на некоторый коэффициент.

>А почему бы векторные комманды CPU не использовать?

tailgunner тебе уже ответил.

>> А почему бы не использовать векторные команды сразу нескольких CPU? %)

> А синхронизация не сожрет больше ресурсов, чем мы какбе надеемся выиграть?

Завсит от конкретных обстоятельств. Естественно, надо проверять поведение и в случае наличия массива длиной 100 и 10 процессоров, и в случае массива из 10000 и 2-х процессоров. И есть надежда, что гипотетический parallel_for_each будет подставлять правильную реализацию.

> Божественный Счетчик Ссылок в смарт-указателях будет захватывать мутекс (InterlockedIncrement для юзерспейса в линукс нет).

Я бы прочитал тебе лекцию о фютексах, спинлоках и lockless-алгоритмах, но лень %) Просто поверь - и в Линуксе есть разные примитивы синхронизации, с разными tradeoff'ами, применяемые в разных обстоятельствах.

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

Во-первых, это не противоречит идее хорошо спроектированного библиотечного parallel_for_each, который выбирает оптимальную реализацию в зависимости от обстоятельств. Во-вторых, параллелизм бывает мелко- и крупнозернистый, и с увеличением числа кор именно мелкозернистый параллелизм будет выходить на передний план (ИМХО).

>>А С++ подход - это клепать комбайны "все в одном"? Я знал я знал.

>Еще бы ты не знал -- ты же переносишь свой собственный способ мышления на весь мир.

Ну перекос в сторону статической типизации и непроработанность ABI у динамической провоцирует создание больших монолитных блобов, да. И что такое "перенос собственного способа мышления на весь мир"?

>>>Не говоря уже про то, что нужно организовывать ожидание внешних процессов, контроль их ошибок

>>Это в общем несложно ведь у нас такой глобальный и надежный язык как С++.

>Т.е. на Java ничего этого делать не нужно, правда?

Джава -это не кроссплатформенный язык, Джава это платформа (Ц) Строуструп. На С++, как на Ъ-кроссплатформенном языке, должна быть интеракция с целевой платформой или как?

>>Отнюдь нет. Линукс более устойчив чем оффтопег отчасти поскольку в нем не принято делать огромные комбайны с кучей in-proc COM компонентов и тредов.

>Linux временами производит впечатление более устойчивого, но лишь за счет того, что под него программирует в несколько тысяч раз меньше ламеров, чем под оффтопик.

Под оффтопег пишут в основном оплачиваемые профессионалы и тестерамы. Под линукс - студенты, энтузиасты и профессионалы после работы либо между делом, зачастую через Ж. Однако он стабильней поскольку концепт менее критичен к ошибкам.

>>>Религия ЛОР-а запрещает писать кроссплатформенный код?

>>Ну хорошо, fork+exec в оффтопике придется заменить на CreateProcess()

>А теперь сам подумай: что проще -- иметь один код по запуску нескольких нитей (который практически не будет меняться на большинстве платформ) или возиться с fork/exec/CreateProcess+вся прелесь по организации pipe/files? И добавь сюда накладные расходы.

Тредовое API в линуксе и винде тоже разное. В wine например эмуляцию виндового мультитрединга описывают как подвиг изобретательного гения. Если ограничиться однозначно соответствующим API, то это будет одинаково плохо работать и там и там.

>>>Ну сделай вьюшку для поиска минимума/максимума в последовательности чисел.

>>В 15K элементов? А правильная ли структура данных выбрана?

>А какие ты структуры данных знаешь правильные? Например, для хранения 15K "сырых" результатов замеров (скажем, со счетчика энергопотребления, или расхода воды, или даже ускорителей (ты представляешь, какими объемами оперировали в BaBar-проекте?)).

Относительно ковыряния в экспериментальных данных не скажу, но есть такая структура данных как "куча" где максимальный элемент всегда висит наверху и операции по поддержке этого свойства при добавлении/изъятии элементов имеет сложность O(log(N)). Используется в std::priority_queue например.

>>>Или для умножения этой же последовательности на некоторый коэффициент.

>>А почему бы векторные комманды CPU не использовать?

>tailgunner тебе уже ответил.

std::for_each оперирует индивидуальными элементами, а векторные комманды CPU AFAIU оперируют блоками.

>Я не называл это поддержкой ФП на уровне языка.

Ну так перечитай ветку, на мой пост из которой ты отвечал. Я там прямым языком спросил "ты называешь буст поддержкой ФП на уровне языка?", после чего плюсатнег начал жестко съежжать и пытатся перейти на личности, потому что почуял слив. Тебя покусал ананимус с дислексией?

>поддержка ФП библиотеками лучше, чем поддержка ФП на уровне языка.

Гы. Ну раз так говорит Светило мировой CS, Мистер ЧСВ, Человек Которому Жмет Череп, то конечно же создатели ФЯП уже бегут в панике в направлении стены...

>но с тобой об этом еще рано говорить -- подучись немного.

Да, да, да. Конечно же здесь ты будешь решать кому подучится и кому что говорить. Вот только когда огласишь на каком ты курсе(в каком классе?), а то что-то очень подозрительно ты шифруешься...

> И что такое "перенос собственного способа мышления на весь мир"?

Например, утверждение: "Под оффтопег пишут в основном оплачиваемые профессионалы и тестерамы. Под линукс - студенты, энтузиасты и профессионалы после работы либо между делом, зачастую через Ж."

> Тредовое API в линуксе и винде тоже разное.

Тем не менее, C++библиотеки, обеспечивающие ОО-обертки вокруг потоков, очень успешно поддерживают как WinAPI, так и Posix.

> Относительно ковыряния в экспериментальных данных не скажу, но есть такая структура данных как "куча" где максимальный элемент всегда висит наверху и операции по поддержке этого свойства при добавлении/изъятии элементов имеет сложность O(log(N)). Используется в std::priority_queue например.

Ради интереса попробуй провести эксперимент: заполни std::map или std::priority_queue 10K элементами. И сделай то же самое с std::vector с последующим std::sort. Будешь сильно удивлен получившимся разрывом в производительности.

> std::for_each оперирует индивидуальными элементами, а векторные комманды CPU AFAIU оперируют блоками.

А что, если индивидуальные элементы являются структурами (начиная от комплексных чисел до более сложных конструкций)?

>Ради интереса попробуй провести эксперимент: заполни std::map или std::priority_queue 10K элементами. И сделай то же самое с std::vector с последующим std::sort. Будешь сильно удивлен получившимся разрывом в производительности.

У std::priority_queue дефолтовый тип стоража - std::vector. А сложность операции build_heap - N*log(N) как и у std::sort.

Re^2: Страуструп о будущем семантических средств разработки с комментариями

>>поддержка ФП библиотеками лучше, чем поддержка ФП на уровне языка.

> Гы. Ну раз так говорит Светило мировой CS, Мистер ЧСВ, Человек Которому Жмет Череп, то конечно же создатели ФЯП уже бегут в панике в направлении стены...

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

>> Интуиция тебе подвела. Ты можешь сам объявить свойственным для языка способом например X Y Z, и они будут так же работать, как и _1 _2 _3.

>Ну и что, я могу от этих _1 взять адрес?

У него унарный operator& перегружен =). Таким макаром конструкция вида &_1 порождает функтор который возвращает адрес аргумента.

std::vector<void*> arr(10);
std::for_each(arr.begin(), arr.end(), &_1);

Теперь каждый указатель в arr содержит свой собственный адрес.

> Ну раз так говорит Светило мировой CS, Мистер ЧСВ, Человек Которому Жмет Череп

Когда ты научишься различать заботу о ЧСВ и удобном языке программирования?

> то конечно же создатели ФЯП уже бегут в панике в направлении стены...

Зря бегут. Их можно понять -- реализация ФП через язык проще, чем через библиотеку. Но последний вариант более интересен.

> а то что-то очень подозрительно ты шифруешься...

Ха-ха-ха. http://www.google.com/search?q=site%3Awww.linux.org.ru+www_linux_org_ru+%D0%B...

Re^8: Страуструп о будущем семантических средств разработки с комментариями

>>> Интуиция тебе подвела. Ты можешь сам объявить свойственным для языка способом например X Y Z, и они будут так же работать, как и _1 _2 _3.

>>Ну и что, я могу от этих _1 взять адрес?

> У него унарный operator& перегружен =). Таким макаром конструкция вида &_1 порождает функтор который возвращает адрес аргумента.

Ну тогда может всё и не так плохо. Хотя Абсурдовскому недоверию к "long(long)" я тоже сочувствую.

> Я бы прочитал тебе лекцию о фютексах, спинлоках и lockless-алгоритмах, но лень %)

Я хочу лекцию :-) но можно и хорошие ссылки (гугль не предлагать)

>Хотя Абсурдовскому недоверию к "long(long)" я тоже сочувствую.

Что тут доверять - взяли, язык подлатали: был long(*)(long) - т.е указатель на функцию, но для нужд буста сделали новый тип long(long), т.е тип "функция в натуре" и compile-time средства для анализа этого типа. Это скорее к вопросу о неограниченной расширяемости языка с помощью шаблонов: не получается шаблончег - пиши патч к g++.

>> Я бы прочитал тебе лекцию о фютексах, спинлоках и lockless-алгоритмах, но лень %)

>Я хочу лекцию :-) но можно и хорошие ссылки (гугль не предлагать)

А толку то? Неужели буст использует все это? Не помню чтобы даже хорошие плюсовые библиотеки поднимались выше уровня InterlockedIncrement/InterlockedDecrement и EnterCriticalSection/LeaveCriticalSection.

>> Я бы прочитал тебе лекцию о фютексах, спинлоках и lockless-алгоритмах, но лень %)

> Я хочу лекцию :-) но можно и хорошие ссылки (гугль не предлагать)

Ы... ну ты-то должен уметь пользоваться Вики

http://en.wikipedia.org/wiki/Futex

"A futex consists of a piece of memory (an aligned integer) that can be shared among processes; it can be incremented and decremented by atomic assembler instructions, and processes can wait for the value to become positive. Futex operations are done almost entirely in userspace; the kernel is only involved when a contended case requires arbitration"

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

http://en.wikipedia.org/wiki/Spinlock

"Spinlocks are efficient if threads are only likely to be blocked for a short period of time, as they avoid overhead from operating system process re-scheduling or context switching."

http://en.wikipedia.org/wiki/Lock-free_and_wait-free_algorithms

Статья по lockless излишне наукообразная. Хотя там тоже есть интересные ссылки, лучше искать в материалах Ottawa Linux Symposium - одно время lockless алгоритмы были в моде у разрабов ядра.

Всё это вместе дает довольно обширный выбор специализаций гипотетических parallel_* операций в плюсах :)

>Что тут доверять - взяли, язык подлатали: был long(*)(long) - т.е указатель на функцию, но для нужд буста сделали новый тип long(long), т.е тип "функция в натуре" и compile-time средства для анализа этого типа.

Угу, подлатали, году эдак в 98-м, когда стандарт принимали.

>Это скорее к вопросу о неограниченной расширяемости языка с помощью шаблонов: не получается шаблончег - пиши патч к g++.

(из-под стола): пиши еще! :))))))

> Не помню чтобы даже хорошие плюсовые библиотеки поднимались выше уровня InterlockedIncrement/InterlockedDecrement и EnterCriticalSection/LeaveCriticalSection.

А это самые быстрые примитивы :) Правда, не припомню, чтобы они использовались в Линуксе :D

>>Что тут доверять - взяли, язык подлатали: был long(*)(long) - т.е указатель на функцию, но для нужд буста сделали новый тип long(long), т.е тип "функция в натуре" и compile-time средства для анализа этого типа.

>Угу, подлатали, году эдак в 98-м, когда стандарт принимали.

Александреску изобретал телеги вида Loki::Functor<long, LOKI_TYPELIST_1(long)> видимо оттого что плохо знал Стандарт.

>>Это скорее к вопросу о неограниченной расширяемости языка с помощью шаблонов: не получается шаблончег - пиши патч к g++.

>(из-под стола): пиши еще! :))))))

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

>Можешь изголяться сколько хочешь, но в пресловутом лиспе львиная доля функциональности реализована библиотеками.

Ну вот как раз Лисп мультипарадигменый язык, и много нужной функциональности поддерживаются им напрямую. Да, я считаю, что функции должны быть ферст класс ситизенами и у тебя не получится меня переубедить :) А КЛОС входит в стандарт и никаких сторонних билиотек для использования ООП инклудить не требуется.

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

Полностью согласен.

>Когда ты научишься различать заботу о ЧСВ и удобном языке программирования?

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

>Зря бегут. Их можно понять -- реализация ФП через язык проще, чем через библиотеку. Но последний вариант более интересен.

Это твое мнение...

>Ха-ха-ха. http://www.google.com/search?q=site%3Awww.linux.org.ru+www_linux_org_ru+%D0%B.. .

Ты себя сильно переоцениваешь, если считаешь, что я буду что-то о тебе гуглить.

> Перечитай свои посты. "Ну вы тут все дурачки и я это не собираюсь подтвержать аргументами так как мне лень но можете попробовать провести для меня исследования и возможно я вас повышу".

Не так, а вот так:

Такую глупую критику плюсов, как у тебя (типа сократить к-во целых типов) читать бестолку, но если ты все же проведешь исследование (не для меня, а для создания хорошего языка для всех), то тебя будет читать интересно и полезно.

> Ты себя сильно переоцениваешь, если считаешь, что я буду что-то о тебе гуглить.

Я хотел помягче сказать, но видимо придется выдать первоначальный вариант: это не я шифруюсь, это ты гуглить не умеешь.

Подозреваю что языки программирования интереснее, чем моя персона.