>Т.е. ты считаешь, что разработчики cups, flac, mpcdec, zlib и т.д. - дауны.

Ну эти проекты написаны на Си а не на ++. То что они зачем-то тащат элементы другого языка в хедерах - дело их личного альтруизма.

>Продолжай играть со своей попкой в гордом одиночестве, товарищ.

Я давно заметил признаки анальной психопатической девиации в твоих мессагах. Буквоедство, неразумный педантизм, какое-то "анальное рабство", "игры с попкой", "геи", призывы "убрать за собой" итп. Слишком сурово и неделикатно приучали к горшку?

>А для указателей стало быть надобность есть? Absurd * (*) (16.09.2008 19:33:44)

Была. Можно было вообще все указатели объявлять как far, но тогда считалось, что это непозволительная трата ресурсов, компьютеры тогда были большие и медленные, а программы маленькие и быстрые :)

> Кнут, очевидно

Арт оф Компьютер Программинг ? Оригинально сокращение написал :-)

>1) extern "C" {} нужен чтобы вызывать С++-функции из Си (отключает манглинг)

Для того чтобы вызвать С функцию из С++ кода , компилятору нужно указать что имя функции подчиняется правилам C , а не С++ . Иначе линковщик очень обидется :-) Без extern "C" , в обьектном файле будет вызов функции с "замангленным" именем , которая очевидно нигде не определена.

Признаюсь честно: ниасилил :) Абелсон-то у нас в универе был на первом курсе. На скиме писали... Золотое время было.

> Абелсон-то у нас в универе был на первом курсе.

Лично? Если нет, то что за ВУЗ?

В смысле, лично? Universität Hannover :)

>В смысле, лично? Universität Hannover :)

Хых.. ПТУ-шник :/

>Для того чтобы вызвать С функцию из С++ кода , компилятору нужно указать что имя функции подчиняется правилам C , а не С++ . Иначе линковщик очень обидется :-) Без extern "C" , в обьектном файле будет вызов функции с "замангленным" именем , которая очевидно нигде не определена.

Дык, о том и речь. Пока не один язык, кроме с++, на это не способен.

Ну ещё, может, D. Но для применения он пока не пригоден.

> Дык, о том и речь. Пока не один язык, кроме с++, на это не способен.

Не надо свистеть. В .NET замечательно FFI сделан, P/Invoke генерится ничуть не сложнее чем в случае с extern "C" { ... }

Не надо свистеть. В .NET замечательно FFI сделан, P/Invoke генерится ничуть не сложнее чем в случае с extern "C" { ... }

.NET не удовлетворяет второму пункту, а следовательно идёт в топку автоматически.

> Перестань пытаться перейти на личности. Ты сел в лужу. Или обосновывай где ты в крестах поддержку ФП увидил, либо признавай слив. С примерами плз. Первый пример пусть будет демонстрировать как мне вернуть апвард фунарг. Время пошло.

Вообще-то сидриановский пафос был направлен eao197, но отвечу я (можно?).

Видимо, кто-то из взрослых дядей испугал ребенка Sidrian-а "фунарг-проблемой". И теперь, даже будучи в 8-м классе, он думает, что все при словах "апвард фунарг" забьются в угол в истерике.

Проблемой это было почти сорок лет назад для лиспа и для недоязыков типа паскаля. В С++, не имея вложенных функций и имея семантику копирования, апвард фунарг вернуть очень просто.



#include <iostream>
#include "boost/function.hpp"
#include "boost/lambda/lambda.hpp"

using namespace std;
using namespace boost;
using namespace boost::lambda;

static long* jptr=NULL;

function<long(long)> f(long i) { long j=i; jptr=&j; return 10*j+_1; }

int main()
{
function<long(long)> g=f(12345678);
cout << "j=" << *jptr << '\n';
*jptr=654321;
cout << "j=" << *jptr << '\n';
cout << "g(9)=" << g(9) << '\n';
return 0;
}

Та прога выводит

j=12345678
j=654321
g(9)=123456789

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

> Проблемой это было почти сорок лет назад для лиспа и для недоязыков типа паскаля. В С++, не имея вложенных функций и имея семантику копирования, апвард фунарг вернуть очень просто.

Лучше б для примера вернул по ссылке класс с перегруженным operator(). Выглядит так же, а интуитивно нехороших конструкций вроде "_1" нет. Да и не даст повода некоторым личностям лишний раз срефлексировать на буст.

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

Да пусть рефлексируют. Все равно уже не долго осталось -- C++0x не за горами, а в нем лямбдами можно будет пользоваться и без буста.

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

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

> Да пусть рефлексируют. Все равно уже не долго осталось -- C++0x не за горами, а в нем лямбдами можно будет пользоваться и без буста.

А когда это можно будет использовать в деле? Ждём реализации ещё 10 лет :)

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

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

>Да пусть рефлексируют. Все равно уже не долго осталось -- C++0x не за горами, а в нем лямбдами можно будет пользоваться и без буста.

10 лет назад в ФИДО был тот же самый вялотекущий маразм "вот дождемся поддержки Стандарта - и заживам".

> Лучше б для примера вернул по ссылке класс с перегруженным operator().

Я так и сделал (только не по ссылке)

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

Не понял. Почему тебе _1 не нравится???

>function<long(long)>

Как Loki::Functor разбирает сигнатуру я допустим знаю поскольку раньше меня интересовали такие вещи. Как эта херня работает - даже разбираться не хочу. Достаточно априорного знания что типа long(long) не существует -> это ошибочная конструкция, почему это компилируется не 2.71бет, но ошибок в коде быть не должно.

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

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

> Не понял. Почему тебе _1 не нравится???

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

То есть, если я вижу что-то вроде:
proc lambdaeval {__arglist __body args} {
lassign $args {*}$__arglist
eval $__body
}

то для меня этого уже достаточно, чтобы такой код не использовать, ибо здесь кривость засела by design.

>> Да пусть рефлексируют. Все равно уже не долго осталось -- C++0x не за горами, а в нем лямбдами можно будет пользоваться и без буста.

>А когда это можно будет использовать в деле? Ждём реализации ещё 10 лет :)

У меня складывается впечатление, что если окончательный черновой вариант стандарта примут в этом году (как и собираются), то в GCC возможностями C++0x можно будет воспользоваться уже в следующем, 2009-м (судя по прогрессу в GCC 4.3 и 4.4 -- http://gcc.gnu.org/gcc-4.4/cxx0x_status.html). И если не в продакшене, то хотя бы в качестве знакомства с новыми возможностями на мелких задачках. А там и другие компиляторы не заставят себя ждать, включая Comeau и VC++. Насколько мне известно, недавно вышедший CodeGear C++Builder 2009 уже поддерживает часть нововведений из C++0x (http://www.codegear.com/products/cppbuilder/whats-new/) и реализацию библиотек TR1. Так же TR1 доступен в виде сервис пака к одной из версий VC++ (то ли 2005, то ли 2008).

В любом случае сейчас C++0x гораздо ближе к реальности, чем года 2-3 назад.

>В любом случае, безотносительно плюсов, начинать _сегодня_ разработку на том, что общают поправить _завтра_ (ну или добавить очень нужную фичу) -- очень рискованное решение. То есть что на D, что на питон 3.0, что на vala, что на цппох сегодня ставить неразумно.

По поводу D и vala согласен.

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

>#include <iostream>
>#include "boost/function.hpp"
>#include "boost/lambda/lambda.hpp"

>using namespace std;
>using namespace boost;
>using namespace boost::lambda;

>static long* jptr=NULL;

>function<long(long)> f(long i) { long j=i; jptr=&j; return 10*j+_1; }

>int main()
>{
>function<long(long)> g=f(12345678);
>cout << "j=" << *jptr << '\n';
>*jptr=654321;
>cout << "j=" << *jptr << '\n';
>cout << "g(9)=" << g(9) << '\n';
>return 0;
>}

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

>В сорсы смотреть лень, но там, наверно, эти _1, _2 и т.д. генерируются каким-нибудь несвойственным для языка способом.

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

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

>>В сорсы смотреть лень, но там, наверно, эти _1, _2 и т.д. генерируются каким-нибудь несвойственным для языка способом.

> Наверняка это класс у которого перегружены все operator-ы таким образом что сохраняют в лямбде саму операцию и один из ее аргументов. А operator() перегружен таким образом что он применяет операцию к операнду, используя вторым операндом сохраненный аргумент и возвращает результат.

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

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

Нельзя ни в чем быть уверенным наверняка: ничего не поделаешь, это С++.

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

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

> Нельзя ни в чем быть уверенным наверняка: ничего не поделаешь, это С++.

Без сорсов или чёткого описания вообще ни в чём уверенным быть нельзя. И цпп тут совершенно не при чём.

> Нельзя ни в чем быть уверенным наверняка: ничего не поделаешь, это С++.

Это жизнь, парень.

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

>> Нельзя ни в чем быть уверенным наверняка: ничего не поделаешь, это С++.

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

Ну посмотри ты в сорцы лямбды: чаво ты там найдешь? Кучу #ifdef - ов, свидетельствующих о том что разрабы тоже мало в чем уверены наверняка.

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

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

> Ну посмотри ты в сорцы лямбды: чаво ты там найдешь? Кучу #ifdef - ов, свидетельствующих о том что разрабы тоже мало в чем уверены наверняка.

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

А вообще, вот хороший плюс использования оперсорсных либ: можно посмотреть в сорсы и сразу понять, стоит ли вообще с либой связываться.

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

>> Ну посмотри ты в сорцы лямбды: чаво ты там найдешь? Кучу #ifdef - ов, свидетельствующих о том что разрабы тоже мало в чем уверены наверняка.

>Мне и _1 хватило для того, чтобы это обходить стороной.

Саттер рекоммендует использовать алгоритмы и лямбду вместо for-лупов, типо std::bind1st и std::bind2nd - это неудачная шутка, а for-лупы ненаглядны. Как все это вяжется с "наглядностью" полотнищ об ошибках и "микроядерностью" языка я правда не совсем понимаю.

>Саттер рекоммендует использовать алгоритмы и лямбду вместо for-лупов, типо std::bind1st и std::bind2nd - это неудачная шутка, а for-лупы ненаглядны.

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

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

>Как все это вяжется с "наглядностью" полотнищ об ошибках и "микроядерностью" языка я правда не совсем понимаю.

Это временная проблема, которую устранят в C++0x.

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

> Саттер рекоммендует использовать алгоритмы и лямбду вместо for-лупов, типо std::bind1st и std::bind2nd - это неудачная шутка, а for-лупы ненаглядны. Как все это вяжется с "наглядностью" полотнищ об ошибках и "микроядерностью" языка я правда не совсем понимаю.

Ну std::for_each действительно в записи гораздо нагляднее for(type::iterator i=bb.begin(); i!=bb.end(); ++I) ... Хотя без нормальных лямбд (лямбды из цппох для меня достаточно "нормальны") всё преимущество сводится на нет.

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

> Так же for_each может быть прозрачно заменен на версию, выполняющую параллельный проход по контейнеру с использованием многоядерных процессоров. Тогда как переделать под такой режим for -- можно обкакаться.

Нифига не "прозрачно". Объект, передаваемый в качестве функции на вход std::for_each может иметь внутреннее состояние, в результате чего задача его нраспараллеливания в общем случае становится нетривиальной.

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

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

>>Как все это вяжется с "наглядностью" полотнищ об ошибках и "микроядерностью" языка я правда не совсем понимаю.

>Это временная проблема, которую устранят в C++0x.

Нет ничего более постоянного чем временное. Про то что вот уже 10 лет плюсофилы молюццо на т.н Стандарт я уже писал выше.

Прозрачно, это когда std::for_each заменяется на std::parallel_for_each.

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

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

Нет, предлагаю делать это после прохода по массиву из, например, 10K элементов.

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

> Прозрачно, это когда std::for_each заменяется на std::parallel_for_each.

Я уже указал почему его нельзя просто так sed-ом заменить. Хотя да, если объект не имеет внутреннего состояния, то заменить действительно легко.

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

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

>Нет, предлагаю делать это после прохода по массиву из, например, 10K элементов.

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

>>Нет, предлагаю делать это после прохода по массиву из, например, 10K элементов.

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

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

Причем, на таких задачах 15K записей -- это мелочи.

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

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

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

>>>Нет, предлагаю делать это после прохода по массиву из, например, 10K элементов.

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

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

Кошмар. А не пробовал брать данные из базы курсором и отсылать мессаги по одной? Нахрена их в памяти-то все разом держать?

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

>>Нет, предлагаю делать это после прохода по массиву из, например, 10K элементов.

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

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

>>>Нет, предлагаю делать это после прохода по массиву из, например, 10K элементов.

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

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

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

>А не пробовал брать данные из базы курсором и отсылать мессаги по одной? Нахрена их в памяти-то все разом держать?

А обработка в памяти по любому получается быстрее. Тем более, что ее распараллелить можно.

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

>>А не пробовал брать данные из базы курсором и отсылать мессаги по одной? Нахрена их в памяти-то все разом держать?

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

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

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

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

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

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

>>А не пробовал брать данные из базы курсором и отсылать мессаги по одной? Нахрена их в памяти-то все разом держать?

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

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

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

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

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

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

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

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

Во-первых, молча.

Во-вторых, к вопросу о примерах использования parallel_for_each это не имеет отношения.