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

C>Но вот про "избегайте использовать много мелких объектов и мелких методов" — полный бред.

Не. Для Компакт-фрэймворка, особенно старых версий — это правильная рекомендация. GC там весьма примитивный. Никакой инкрементальной сборки. Так что и правад укрупнение объектов имело смысл. К тому же любой объект занимает лишнее место (для обычного фрэймворка это где-то 12 байт), так что укрупнение может дать выигрыш. Вопрос только в том, что актуальным этот совет будет если в память нужно поднять миллионы объектов. Естественно, что на обычном фрэймворке такой совет полная чушь.

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

VD>На самом деле это многое говорит... о тебе. :))

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

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

C>>Ну во-первых, очень многое поменялось и сейчас 99% WM устройств с .NET CF 3.5
C>>Во-вторых, Вы не видитте разницы между CLR для мобильных телефонов и CLR для полноценных компьютеров?

VD>Этот пример справедлив и для настольного фрэймворка последней версии. Ты вчитайся в код. Там не о экономии на вызове метода речь идет. Там речь о том, что не надо устанавливать размеры окна в два приема, если тоже самое можно сделать за один прием.

Хорошо, тут я был не прав. Привел неудачный пример. Но я действительно неоднократно видел подобные рекомендации — ссылок к сожалению не сохранил, поэтому пытался найти в гугле что есть :) Да и ты сам ниже подтверждаешь мои слова.

Вообще, в чем принципиальное отличие компактного фреймворка от большого — только в том, что последний работает на компьютере с ограниченными ресурсами. И вот тут все прелести managed языков в плане ресурсоемкости и производительности вылезают во всей красе. Только и всего. На десктопе, и особенно на сервере этого не заметно, или так скажем не так явно заметно. Вот только пользователи жалуются — типа установил консоль оракла написанную на яве и ничего больше запустить не могу, съела всю память :)

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

C>>Ну во-первых, очень многое поменялось и сейчас 99% WM устройств с .NET CF 3.5
C>>Во-вторых, Вы не видитте разницы между CLR для мобильных телефонов и CLR для полноценных компьютеров?

VD>Этот пример справедлив и для настольного фрэймворка последней версии. Ты вчитайся в код. Там не о экономии на вызове метода речь идет. Там речь о том, что не надо устанавливать размеры окна в два приема, если тоже самое можно сделать за один прием.

Да это не важно. Суть, что человек пытается судить о производительности .NET FW по .NET CF 1.0, что есть полная глупость. Это в духе того сравнения, которое сделал Шеридан недавно: что мол GUI на виндовом сервере тормозит сервер потому, что на его криво настроенном линуксовом сервере X Window подсистема кушает 10% процессорного времени...

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


C>>Быстрый код получается не тогда, когда Вы тратите 90% времени на техническую оптимизацию кода и 10% на алгоритмизацию, а 90% на алгоритмизацию, 10% на техническую оптимизацию.

VD>Назвать тот бред, что ты перечислил оптимизациями вообще язык не поворачивается. Ту чушь оптимизируют компиляторы (JIT или обычные). Ручное вмешательство там на сегодня только вредит, так как нарушает те самые партерный что оптимизируются компиляторами.

Вы это мне? Я как бы в курсе.

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

VD>>На самом деле это многое говорит... о тебе.

COF>Я просто стараюсь избегать преждевременной пессимизации кода.

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

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

C>>>Ну во-первых, очень многое поменялось и сейчас 99% WM устройств с .NET CF 3.5
C>>>Во-вторых, Вы не видитте разницы между CLR для мобильных телефонов и CLR для полноценных компьютеров?

VD>>Этот пример справедлив и для настольного фрэймворка последней версии. Ты вчитайся в код. Там не о экономии на вызове метода речь идет. Там речь о том, что не надо устанавливать размеры окна в два приема, если тоже самое можно сделать за один прием.

COF>Хорошо, тут я был не прав. Привел неудачный пример. Но я действительно неоднократно видел подобные рекомендации — ссылок к сожалению не сохранил, поэтому пытался найти в гугле что есть Да и ты сам ниже подтверждаешь мои слова.

COF>Вообще, в чем принципиальное отличие компактного фреймворка от большого — только в том, что последний работает на компьютере с
Это не отличие фреймворка. Это отличие рабочих условий.
COF>ограниченными ресурсами. И вот тут все прелести managed языков в плане ресурсоемкости и производительности вылезают во всей красе. Только и всего. На десктопе, и особенно на сервере этого не заметно, или так скажем не так явно заметно. Вот только пользователи жалуются — типа установил консоль оракла написанную на яве и ничего больше запустить не могу, съела всю память
А вот у меня на WM6.1 устройстве с .NET CF 3.5 есть три приложения на .NET CF и визуально по производительности они ничуть не уступают приложениям на С++ (MFC) — летают.

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

COF>>Вообще, в чем принципиальное отличие компактного фреймворка от большого — только в том, что последний работает на компьютере с
C>Это не отличие фреймворка. Это отличие рабочих условий.
COF>>ограниченными ресурсами. И вот тут все прелести managed языков в плане ресурсоемкости и производительности вылезают во всей красе. Только и всего. На десктопе, и особенно на сервере этого не заметно, или так скажем не так явно заметно. Вот только пользователи жалуются — типа установил консоль оракла написанную на яве и ничего больше запустить не могу, съела всю память :)
C>А вот у меня на WM6.1 устройстве с .NET CF 3.5 есть три приложения на .NET CF и визуально по производительности они ничуть не уступают приложениям на С++ (MFC) — летают.

Хорошо, что это за приложения? Я их поставлю и если они действительно летают, то я признаю свою неправоту :)

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

ГВ>>Ровно то же самое делается на C++: bind(&X::SomeMethod, _1) == someValue. И тоже, знаешь ли, полноценное лексическое замыкание. В конце концов, главное при создании замыкания что? ИМХО — связать переменные локального контекста с параметрами (или переменными) некоторой функции. Совершенно не важно, используем мы ссылки или значения.
G>Важно. Если связать что-нить с объектом в хипе, выделенном в текущем скоупе, и время жизни лямбды больше, чем текущий скоуп, то получится утечка.

А... Так ты про согласование жизненных циклов? Ну тогда да. Только это не "связывание", вроде, а "согласование ЖЦ".

ГВ>>По-моему, не стоит впадать в крайности и считать "полноценным" замыканием только такое, которое использует ссылки в стиле C#.
G>Не надо торговаться. лямбды и замыкания в С++ ущербны.

Не "ущербны", а специфичны для C++. У любого языка есть своя специфика.

ГВ>>Но и в том, и в другом случае программист описывает, что именно связыватся.
G>Нет, в случае C# программист пишет функцию. Ему не надо вникать что там внутри компилятора происходит. В случае C++ он должен заниматься сввязыванием.

Ну всё, я уже понял. C++-ник должен отследить согласованность ЖЦ. Да, это есть, хотя и далеко от чудовищной проблемности, приписываемой такому подходу. Ну и опять таки.... Ладно, хватит уже про shared_ptr.

ГВ>>Как это — нет? А новый стандарт? А новый компилятор от MS (который, правда, я ещё не щупал)? Всё есть, вроде. И опять таки, bind — пусть и не полноценная замена, но по крайней мере, для "маленьких функций" — вполне подходящее решение. Примечательно же оно тем, что получено средствами самого C++.
G>Ну и где этот стандарт?

Планируется к принятию. Компилятор, AFAIK, уже вышел. (Можно подумать, что появись этот стандарт прямо сейчас, что-то бы изменилось в твоей риторике! Ага, верю я...)

ГВ>>Хм. Я бы так не сказал, поскольку Traits используются для конструирования типа (для инстанцирования RegisterDep). Ну а сами RegisterDep просто зависят от типа используемого конструктора (учтём, что сигнатура = тип функции), точно так же, как и любая функция требует параметров вполне определённых типов.
G>Это и есть метаданные типов.

Понятно. Значит, любую привязку к типу сейчас нужно называть использованием метаданных. А мужики-то...

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

А как контейнер вычислит, что мне нужен именно определённый конструктор? Допустим, что у объекта два конструктора, оба с двумя аргументами, типы которых известны контейнеру. Контейнер сам примет решение? А на основании каких критериев?

G>Ты считаешь что описание количества и типов параметров конструктора, совмещенное с методами создания объекта, не является метаданными?
G>Не стоит себя обманывать.

Хм. Это есть явное указание типа (сигнатуры) используемого конструктора. Где тут метаданные? От цифр в названиях методов можно избавиться.

G>На type_info все не заменишь, типизированность пропадет, генериков в рантайме у С++ нету.

Как это — типизированность пропадёт? Какая? Где? std::string(raw_name) и полный вперёд!

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

COF>>>Вообще, в чем принципиальное отличие компактного фреймворка от большого — только в том, что последний работает на компьютере с
C>>Это не отличие фреймворка. Это отличие рабочих условий.
COF>>>ограниченными ресурсами. И вот тут все прелести managed языков в плане ресурсоемкости и производительности вылезают во всей красе. Только и всего. На десктопе, и особенно на сервере этого не заметно, или так скажем не так явно заметно. Вот только пользователи жалуются — типа установил консоль оракла написанную на яве и ничего больше запустить не могу, съела всю память
C>>А вот у меня на WM6.1 устройстве с .NET CF 3.5 есть три приложения на .NET CF и визуально по производительности они ничуть не уступают приложениям на С++ (MFC) — летают.

COF>Хорошо, что это за приложения? Я их поставлю и если они действительно летают, то я признаю свою неправоту
ThrottleLauncher, Twittula и самописное бизнес-приложение.

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

ГВ>>>По-моему, не стоит впадать в крайности и считать "полноценным" замыканием только такое, которое использует ссылки в стиле C#.
G>>Не надо торговаться. лямбды и замыкания в С++ ущербны.
ГВ>Не "ущербны", а специфичны для C++. У любого языка есть своя специфика.
Не надо торговаться, не на рынке находимся.

ГВ>>>Но и в том, и в другом случае программист описывает, что именно связыватся.
G>>Нет, в случае C# программист пишет функцию. Ему не надо вникать что там внутри компилятора происходит. В случае C++ он должен заниматься сввязыванием.
ГВ>Ну всё, я уже понял. C++-ник должен отследить согласованность ЖЦ. Да, это есть, хотя и далеко от чудовищной проблемности, приписываемой такому подходу. Ну и опять таки.... Ладно, хватит уже про shared_ptr.
Какую согласованность, какого ЖЦ? Придумыванием терминов ущербность не скрыть.

ГВ>>>Как это — нет? А новый стандарт? А новый компилятор от MS (который, правда, я ещё не щупал)? Всё есть, вроде. И опять таки, bind — пусть и не полноценная замена, но по крайней мере, для "маленьких функций" — вполне подходящее решение. Примечательно же оно тем, что получено средствами самого C++.
G>>Ну и где этот стандарт?
ГВ>Планируется к принятию. Компилятор, AFAIK, уже вышел. (Можно подумать, что появись этот стандарт прямо сейчас, что-то бы изменилось в твоей риторике! Ага, верю я...)
Про стандарт уже давно говорят, а его пока нет.

ГВ>>>Хм. Я бы так не сказал, поскольку Traits используются для конструирования типа (для инстанцирования RegisterDep). Ну а сами RegisterDep просто зависят от типа используемого конструктора (учтём, что сигнатура = тип функции), точно так же, как и любая функция требует параметров вполне определённых типов.
G>>Это и есть метаданные типов.

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

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

ГВ>А как контейнер вычислит, что мне нужен именно определённый конструктор? Допустим, что у объекта два конструктора, оба с двумя аргументами, типы которых известны контейнеру. Контейнер сам примет решение? А на основании каких критериев?
На основании каких хочет, это его дело.

G>>Ты считаешь что описание количества и типов параметров конструктора, совмещенное с методами создания объекта, не является метаданными?
G>>Не стоит себя обманывать.
ГВ>Хм. Это есть явное указание типа (сигнатуры) используемого конструктора. Где тут метаданные? От цифр в названиях методов можно избавиться.
От этого метаданные не исчезнут.

G>>На type_info все не заменишь, типизированность пропадет, генериков в рантайме у С++ нету.
ГВ>Как это — типизированность пропадёт? Какая? Где? std::string(raw_name) и полный вперёд!
Ну код в студию: типобезопасное создание в рантайме ообъекта по заданному type_info.

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Ты бы за логической связью последил. Если копирование — это не один из приёмов, который может использоваться для построения замыкания, то... То я прям, не знаю, даже.
Гм. Вообще-то у замыкания есть своя, четко определенная семантика. Копирование, о котором ты говоришь — малоинтересный частный случай.
В общем случае замыкается именно лексический контекст, причем он не readonly:

int sum = 0;
IteratePackageStructure(structure, (item) => sum += item.Size));
Console.WriteLine(sum);

Никакими копированиями эмулировать поведение вот этого маленького фрагмента кода не получится. Придется выполнять замыкание вручную, например написать функтор, у которого sum станет мембером.
ГВ>Это всё понятно, и никто с этим не спорит. Равно как никто и не пытается объявить C++ "чистым ФЯ".
Да, это всего лишь громоздкий и многословный императивный язык.

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

ГВ>>>>По-моему, не стоит впадать в крайности и считать "полноценным" замыканием только такое, которое использует ссылки в стиле C#.
G>>>Не надо торговаться. лямбды и замыкания в С++ ущербны.
ГВ>>Не "ущербны", а специфичны для C++. У любого языка есть своя специфика.
G> Не надо торговаться, не на рынке находимся.

Конечно-конечно. Гораздо правильнее принять "ущербно" вместо "специфично". Дружище, мы не на рынке, но и ты в законодатели терминов ещё не выбился, так что, давай уж согласовывать термины.

ГВ>>Ну всё, я уже понял. C++-ник должен отследить согласованность ЖЦ. Да, это есть, хотя и далеко от чудовищной проблемности, приписываемой такому подходу. Ну и опять таки.... Ладно, хватит уже про shared_ptr.
G>Какую согласованность, какого ЖЦ? Придумыванием терминов ущербность не скрыть.

ЖЦ = жизненный цикл. Если это новый термин, то программирование появилось позавчера.

ГВ>>>>Как это — нет? А новый стандарт? А новый компилятор от MS (который, правда, я ещё не щупал)? Всё есть, вроде. И опять таки, bind — пусть и не полноценная замена, но по крайней мере, для "маленьких функций" — вполне подходящее решение. Примечательно же оно тем, что получено средствами самого C++.
G>>>Ну и где этот стандарт?
ГВ>>Планируется к принятию. Компилятор, AFAIK, уже вышел. (Можно подумать, что появись этот стандарт прямо сейчас, что-то бы изменилось в твоей риторике! Ага, верю я...)
G>Про стандарт уже давно говорят, а его пока нет.

Зато компилятор, AFAIK, уже есть. Жаль, никак руки не доходят его плотно пощупать.

ГВ>>>>Хм. Я бы так не сказал, поскольку Traits используются для конструирования типа (для инстанцирования RegisterDep). Ну а сами RegisterDep просто зависят от типа используемого конструктора (учтём, что сигнатура = тип функции), точно так же, как и любая функция требует параметров вполне определённых типов.
G>>>Это и есть метаданные типов.

ГВ>>Понятно. Значит, любую привязку к типу сейчас нужно называть использованием метаданных. А мужики-то...
G>Не любую привзку типу, а любые структуры данныих или методы, которые так или иначе описывают некоторый тип и его содержимое.

Э... Что-то опять новенькое. Я как-то привык считать, что метаданные нужны для того, чтобы сопоставить типу (или объекту) какие-то параметры, о которых сам тип (объект) и слыхом не слыхивал. Meta = "над".

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

ГВ>>А как контейнер вычислит, что мне нужен именно определённый конструктор? Допустим, что у объекта два конструктора, оба с двумя аргументами, типы которых известны контейнеру. Контейнер сам примет решение? А на основании каких критериев?
G>На основании каких хочет, это его дело.

Нет, Девид Блейн... Я таких вольностей свои программам не позволяю.

G>>>Ты считаешь что описание количества и типов параметров конструктора, совмещенное с методами создания объекта, не является метаданными?
G>>>Не стоит себя обманывать.
ГВ>>Хм. Это есть явное указание типа (сигнатуры) используемого конструктора. Где тут метаданные? От цифр в названиях методов можно избавиться.
G>От этого метаданные не исчезнут.

Ты видишь суслика? Я, лично, — нет.

G>>>На type_info все не заменишь, типизированность пропадет, генериков в рантайме у С++ нету.
ГВ>>Как это — типизированность пропадёт? Какая? Где? std::string(raw_name) и полный вперёд!
G>Ну код в студию: типобезопасное создание в рантайме ообъекта по заданному type_info.

Если не лень будет, переделаю свой пример, но обещать не буду.

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

ГВ>>Ты бы за логической связью последил. Если копирование — это не один из приёмов, который может использоваться для построения замыкания, то... То я прям, не знаю, даже.
S>Гм. Вообще-то у замыкания есть своя, четко определенная семантика. Копирование, о котором ты говоришь — малоинтересный частный случай.

Смотря что копируется. Копировать можно и ссылки. В остальном проблема передачи параметров замыкания носит ровно тот же самый характер, что и передача параметров в процедуру: по ссылке, по указателю или по значению. Согласование жизненных циклов объектов — из той же оперы.

S>В общем случае замыкается именно лексический контекст, причем он не readonly:

Забавно, что сейчас ты апеллируешь к тому, что иной раз подаётся как преимущество "ФП": отсуствие побочных эффектов. Но это так, в offtop-порядке.

S>

S>int sum = 0;
S>IteratePackageStructure(structure, (item) => sum += item.Size));
S>Console.WriteLine(sum);
S>

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

Скажем так, по состоянию на данный момент такое поведение трудновато реализовать.

ГВ>>Это всё понятно, и никто с этим не спорит. Равно как никто и не пытается объявить C++ "чистым ФЯ".
S>Да, это всего лишь громоздкий и многословный императивный язык.

Да-да, осталось отказаться от замшелых стереотипов... На колу мочало.

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

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

ГВ>>>>>По-моему, не стоит впадать в крайности и считать "полноценным" замыканием только такое, которое использует ссылки в стиле C#.
G>>>>Не надо торговаться. лямбды и замыкания в С++ ущербны.
ГВ>>>Не "ущербны", а специфичны для C++. У любого языка есть своя специфика.
G>> Не надо торговаться, не на рынке находимся.

ГВ>Конечно-конечно. Гораздо правильнее принять "ущербно" вместо "специфично". Дружище, мы не на рынке, но и ты в законодатели терминов ещё не выбился, так что, давай уж согласовывать термины.
Не надо согласовывать, если что-то делается в С++ созданием кучи шаблонов, когда в других языках оно уже есть, то это именно "ущербно".

ГВ>Э... Что-то опять новенькое. Я как-то привык считать, что метаданные нужны для того, чтобы сопоставить типу (или объекту) какие-то параметры, о которых сам тип (объект) и слыхом не слыхивал. Meta = "над".
Правильно, а теперь еще раз перечитай свой код. Очень даже сопоставляется строковое имя типа и количество параметров конструктора с типами аргументов.

G>>>>Ты считаешь что описание количества и типов параметров конструктора, совмещенное с методами создания объекта, не является метаданными?
G>>>>Не стоит себя обманывать.
ГВ>>>Хм. Это есть явное указание типа (сигнатуры) используемого конструктора. Где тут метаданные? От цифр в названиях методов можно избавиться.
G>>От этого метаданные не исчезнут.
ГВ>Ты видишь суслика? Я, лично, — нет.
Это не суслик, а огромный слон.

Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Смотря что копируется. Копировать можно и ссылки. В остальном проблема передачи параметров замыкания носит ровно тот же самый характер, что и передача параметров в процедуру: по ссылке, по указателю или по значению. Согласование жизненных циклов объектов — из той же оперы.
Вот то-то и оно, что в нормальных замыканиях "передача параметров" происходит по ссылке. И параметры образуются неявным образом. А не вручную — вручную можно и функтор напедалить, кто бы спорил. Там и буст не особо нужен.

ГВ>Скажем так, по состоянию на данный момент такое поведение трудновато реализовать.
Об этом речь и идет. Ежу понятно, что "поведение С++" на С++ реализовывать легко и приятно.

ГВ>Да-да, осталось отказаться от замшелых стереотипов... На колу мочало.
Угу. С нетерпением ждем реализации Linq на С++. Хотя бы в объеме библиотеки, т.е. без специального синтаксиса query expressions.
Смею полагать, что "по состоянию на данный момент такое поведение трудновато реализовать".

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

ГВ>>Конечно-конечно. Гораздо правильнее принять "ущербно" вместо "специфично". Дружище, мы не на рынке, но и ты в законодатели терминов ещё не выбился, так что, давай уж согласовывать термины.
G>Не надо согласовывать, если что-то делается в С++ созданием кучи шаблонов, когда в других языках оно уже есть, то это именно "ущербно".

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

ГВ>>Э... Что-то опять новенькое. Я как-то привык считать, что метаданные нужны для того, чтобы сопоставить типу (или объекту) какие-то параметры, о которых сам тип (объект) и слыхом не слыхивал. Meta = "над".
G>Правильно, а теперь еще раз перечитай свой код. Очень даже сопоставляется строковое имя типа и количество параметров конструктора с типами аргументов.

Не совсем так, только строковое имя типа именно сопоставляется с типом и может называться "метаданными типа". А количество параметров конструктора — часть определения самого типа. Понимаешь разницу?

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

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

ГВ>>>Конечно-конечно. Гораздо правильнее принять "ущербно" вместо "специфично". Дружище, мы не на рынке, но и ты в законодатели терминов ещё не выбился, так что, давай уж согласовывать термины.
G>>Не надо согласовывать, если что-то делается в С++ созданием кучи шаблонов, когда в других языках оно уже есть, то это именно "ущербно".
ГВ>Ясно. Значит, ты считаешь такое явление ущербностью со всеми сопутствующими эмоциональными оттенками. На здоровье. Я полагаю это спецификой.


ГВ>>>Э... Что-то опять новенькое. Я как-то привык считать, что метаданные нужны для того, чтобы сопоставить типу (или объекту) какие-то параметры, о которых сам тип (объект) и слыхом не слыхивал. Meta = "над".
G>>Правильно, а теперь еще раз перечитай свой код. Очень даже сопоставляется строковое имя типа и количество параметров конструктора с типами аргументов.
ГВ>Не совсем так, только строковое имя типа именно сопоставляется с типом и может называться "метаданными типа". А количество параметров конструктора — часть определения самого типа. Понимаешь разницу?
И можно у "самого типа" спросить о том какие у него есть конструкторы?

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

ГВ>>Смотря что копируется. Копировать можно и ссылки. В остальном проблема передачи параметров замыкания носит ровно тот же самый характер, что и передача параметров в процедуру: по ссылке, по указателю или по значению. Согласование жизненных циклов объектов — из той же оперы.
S>Вот то-то и оно, что в нормальных замыканиях "передача параметров" происходит по ссылке. И параметры образуются неявным образом. А не вручную — вручную можно и функтор напедалить, кто бы спорил. Там и буст не особо нужен.

C++ предполагает три различных способа передачи параметров: значение, ссылка, указатель. "Нормальные" замыкания, судя по твоему высказыванию — это только ссылка, контролируемая GC. Я не хочу сказать, что такая точка зрения не имеет права на существование, но это никак не противоречит копированиям и прочим тра-ля-ля.

ГВ>>Скажем так, по состоянию на данный момент такое поведение трудновато реализовать.
S> Об этом речь и идет. Ежу понятно, что "поведение С++" на С++ реализовывать легко и приятно.

Ну, я имел в виду, что с бустом сие сложновато будет реализовать. В смысле, именно такую конструкцию — со ссылкой на неконстантную переменную. Но и то, из-за design goals самой BLL (boost lambda library). А так, вроде, C++0x должен содержать такую возможность.

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

ГВ>>Не совсем так, только строковое имя типа именно сопоставляется с типом и может называться "метаданными типа". А количество параметров конструктора — часть определения самого типа. Понимаешь разницу?
G>И можно у "самого типа" спросить о том какие у него есть конструкторы?

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