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

COF>Да уж, такое впечатление что дотнетчики живут в каком-то виртуальном мире, навеянном рекламными проспектами — в мире где нет утечек памяти, где программы летают, а критерием хорошести языка является то, насколько он поддерживает лямбды
С лямбдами однозначно лучше чем без них. Уверен, что если у дотнетчиков резко отнять лямбды и, следовательно linq, они пойдут революцией против M$!
COF>В конце-концов, ну не было в C++ лямбд — ну и черт с ними, вполне можно без них прожить. Что народ к ним привязался?
А кто спорит? Можно. Можно прожить и без рекурсии, и даже без виртуальных методов.

COF>А вот в C# нет деструкторов и переопределения операторов присваивания, например.
Очень много желающих добавить в дотнет что-то. Например, паттерн-матчинг. И очень мало желающих вставить в дотнет деструкторы и операторы присванивания. Они почему-то нужны только C++-никам.
COF>Я конечно понимаю, что если чего-то нет в текущей версии C# — это не нужно, а если чего-то нет в C++ — это плохой дизайн языка, но все же
В C# тоже многого нехватает. Те, кому этого очень сильно не хватает, используют Nemerle и F#.

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

ГВ>>Шутки-шутками, но если заглянуть в .NET GUI, то там прямо таки несколько активных топиков — про производительность. Однако!
C>Давайте загляним в топики в разделе С++.

Даже не заглядывая можно сказать, что производительность — любимая фишка плюсовиков, обсуждается часто и со вкусом. Так что, удивляться нечему.

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

ГВ>>Всё, что не C++ — неправильно.
C>Да, понятно.

Странно. Разве я называл шарповые или, например, лисповые лямбды — "недолямбдами", а сам C# — "недоязыком"? Так что, что-то тебе померещилось не то. Ты меня с кем-то путаешь.

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

Х>>погоди ерепенится, прочтя твоё сообщение я понял что структура изначально таки лежит на стеке, но в момент вызова лямбды она копируется в поле лямбды, своё же сообщение я написал в ответ на сообщение samius'а, в котором написано что структуры, попадающие в scope лямбды никогда не лежат на стеке, так как всё-таки верно?
MK>Замкнутые структуры размещаются в полях класса.
логично, но меня всё же более интересовал вопрос о том, будут ли ети структуры существовать на стеке если они замкнуты.

Х>>если верно второе то ето вообще удивительно, получается что там где в C# вызывается лямбда стековых структур не может быть в принципе, а ето просто неимоверный оверхед.
MK>Ты так шутишь или взаправду считаешь, что 30-40 байт — это НЕИМОВЕРНЫЙ ОВЕРХЕД!?!?!?
оверхед не в памяти, оверхед в скорости аллокации/доступа стек vs heap

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

Х>... я написал в ответ на сообщение samius'а, в котором написано что структуры, попадающие в scope лямбды никогда не лежат на стеке, так как всё-таки верно? если верно второе то ето вообще удивительно, получается что там где в C# вызывается лямбда стековых структур не может быть в принципе, а ето просто неимоверный оверхед.
Не совсем верно. Лямбда не исключает стековых структур. А лексическое замыкание переменных (структур в том числе) реализуется через размещение переменных в классе, который в хипе.
Оверхед — да. Неимоверный — смотря для чего. Хочешь выжать пару тактов — забудь про лямбды и занимайся ручным инлайнингом. А в общем случае — удобно и красиво.

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

COF>>А вот в C# нет деструкторов и переопределения операторов присваивания, например.
S>Очень много желающих добавить в дотнет что-то. Например, паттерн-матчинг. И очень мало желающих вставить в дотнет деструкторы и операторы присванивания. Они почему-то нужны только C++-никам.

Ну так, а потом получается, что программы с GC страдают от утечек памяти. Кому сказать — не поверят :) Такое впечатление, что в ситуации "вам шашечки или ехать", дотнетчики уверенно выбирают шашечки :)

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

Х>оверхед не в памяти, оверхед в скорости аллокации/доступа стек vs heap
ааааа... я понял, ты хипом вообще не пользуешься, всё только в стеке, и пишешь ты только на ассемблере, а то в С++ еще и классы бывают с виртуальными методами, а это, как и хип, непременно неимоверный оверхед!

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

S>Оверхед — да. Неимоверный — смотря для чего. Хочешь выжать пару тактов — забудь про лямбды и занимайся ручным инлайнингом. А в общем случае — удобно и красиво.

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

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

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

G>>>>Стандартные аллокаторы в С++ требуют прохода по списку свободных блоков памяти при выделении\освобождении, эта операция имеет алгоритмическую сложность O(n). При интенсивных операциях выделения\освобождения работает очеень медленно.
Х>>>для интенсивных операций существует пулы/арены
G>>А если у тебя вся программа состоит из таких нтенсивных операций, например высоконагруженный сервер?
Х>даа, вся программа состоит из аллокаций в хипе, такую ещё поискать надо, а как же твои незабвенные 10% кода отнимают 90% ресурсов? или ето не распространяется на высоконагруженные сервера?
Не путай. 10% кода выполняются 90% времени в вычислтеьных задачах.
При высоких нагрузках надо оптимально управлять ресурсами.

Х>ещё раз про замыкания, в c++ ты можешь скопировать весь контекст (синтаксис [=]) и ето будет идентично по семантике с некоторыми лиспами, которые тоже копируют контекст, а не ссылки. Так с чем ты не согласен? то что С++ позволяет программисту оптимально оперировать контекстом? и там где не нужно копирование воспользоваться ссылкой? да, в случае ссылок программист должен учитывать время их жизни, но ето в мире с++ есстесственно, и от етого очевидно лямбды не меняют своего называния.
Мда..
Есть переменная на стеке, надо построить честное замыкание для лямбды. Время жизни лямбды больше текущего скоупа. Что С++ предлагает? Ничего.
Нет полноценных замыканий => нет полноценных лямбд. Твоя демагогия не интересует.

Х>>>во-вторых: лексическое замыкание есть, прочитай теперь ты 3 предыдущие страницы.
G>>Нету. Можно сымитировать подобие лексических замыканий причем со значительными ограничениями.
Х>ещё раз, где иммитация? в чём иммитация?
Читай выше и внимательнее.

Х>>>зайди в раздел .NET или .NET GUI и посмотри темы в которых люди кричат о недостаточной производительности, такое ощущение что избавившись от менеджмента памяти дотнетовцы теперь приседают в борьбе за производительность
G>>Многие проблемы с производительностью от незнания. У меня саого программы на .NET тормозили когда я только начинал на нем писать. Теперь таких проблем нету.
Х>я рад за тебя что у тебя нет проблемм с производительностью, а в коде над которым я работаю нет утечек памяти, и явные delete можно пересчитать по пальцам, и что?
И кто же память освобождает? shared_ptr, так они оверхед создают...

А вообще-то есть статистика. Так вот проблемы с утечками памяти в unmanaged появляют гораздо чаще проблем с производительностью в managed.

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

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

COF>>>А вот в C# нет деструкторов и переопределения операторов присваивания, например.
S>>Очень много желающих добавить в дотнет что-то. Например, паттерн-матчинг. И очень мало желающих вставить в дотнет деструкторы и операторы присванивания. Они почему-то нужны только C++-никам.

COF>Ну так, а потом получается, что программы с GC страдают от утечек памяти. Кому сказать — не поверят
Как связано отсутствие деструкторов и операторов присваивания в дотнете с утечками программ с GC?

COF>Такое впечатление, что в ситуации "вам шашечки или ехать", дотнетчики уверенно выбирают шашечки
Что, программы на дотнете ни разу не ездят впринципе?

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

MK>Здравствуйте, Хвост, Вы писали:

Х>>оверхед не в памяти, оверхед в скорости аллокации/доступа стек vs heap
MK> ааааа... я понял, ты хипом вообще не пользуешься, всё только в стеке, и пишешь ты только на ассемблере, а то в С++ еще и классы бывают с виртуальными методами, а это, как и хип, непременно неимоверный оверхед!
к сожалению ты ничего не понял...
к тебе как к дотнетчику нескромный вопрос, чем занимаешься? вебом али ентерпрайзом? третьего то не дано

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

Х>>погоди ерепенится, прочтя твоё сообщение я понял что структура изначально таки лежит на стеке, но в момент вызова лямбды она копируется в поле лямбды, своё же сообщение я написал в ответ на сообщение samius'а, в котором написано что структуры, попадающие в scope лямбды никогда не лежат на стеке, так как всё-таки верно?
MK>Замкнутые структуры размещаются в полях класса.

А замкнуть "по ссылке" их можно? То есть так, чтобы структура "физически" осталась в стеке конструирующей лямбду функции? Или только "по значению", то есть — копированием в соответствующий экземпляр класса сконструированной лямбды?

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

COF>>Ну так, а потом получается, что программы с GC страдают от утечек памяти. Кому сказать — не поверят :)
S>Как связано отсутствие деструкторов и операторов присваивания в дотнете с утечками программ с GC?

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

COF>>Такое впечатление, что в ситуации "вам шашечки или ехать", дотнетчики уверенно выбирают шашечки :)
S>Что, программы на дотнете ни разу не ездят впринципе?

Медленно и печально :)

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

COF>>В конце-концов, ну не было в C++ лямбд — ну и черт с ними, вполне можно без них прожить. Что народ к ним привязался?
S>А кто спорит? Можно. Можно прожить и без рекурсии, и даже без виртуальных методов.
Да что там лямбды. Десяток страниц назад кто-то доказывал что всю программу можно написать используя один стек.
Даешь офис на стеке

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

Х>>>если верно второе то ето вообще удивительно, получается что там где в C# вызывается лямбда стековых структур не может быть в принципе, а ето просто неимоверный оверхед.
MK>>Ты так шутишь или взаправду считаешь, что 30-40 байт — это НЕИМОВЕРНЫЙ ОВЕРХЕД!?!?!?
Х>оверхед не в памяти, оверхед в скорости аллокации/доступа стек vs heap

Ну и расскажи нам о скорости аллокации стек vs managed heap

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

G>Есть переменная на стеке, надо построить честное замыкание для лямбды. Время жизни лямбды больше текущего скоупа. Что С++ предлагает? Ничего.

Да ёлки ж зелёные! Значения (синоним в данном контексте: копия переменной) плюсовыми лямбдами замыкаются с лёгкостью неимоверной. А дальше — хоть выводи функцию из скопа, хоть прихлопывай.

G>Нет полноценных замыканий => нет полноценных лямбд. Твоя демагогия не интересует.

Не, ну это уже просто феерично.

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

ГВ>А замкнуть "по ссылке" их можно? То есть так, чтобы структура "физически" осталась в стеке конструирующей лямбду функции? Или только "по значению", то есть — копированием в соответствующий экземпляр класса сконструированной лямбды?
Я напишу про общий случай, т.к. спецификацию на язык не читал. Так вот, копирования никакого нет. Компилятор превращает лямбду в класс, у которого поля — это замкнутые переменные, а единственный метод — тело (или как там оно называется) лямбды. Все операторы работающие с замкнутой переменной вне лямбды, переписываются на обращение к полю класса.

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

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

G>>>А если у тебя вся программа состоит из таких нтенсивных операций, например высоконагруженный сервер?
Х>>даа, вся программа состоит из аллокаций в хипе, такую ещё поискать надо, а как же твои незабвенные 10% кода отнимают 90% ресурсов? или ето не распространяется на высоконагруженные сервера?
G>Не путай. 10% кода выполняются 90% времени в вычислтеьных задачах.
G>При высоких нагрузках надо оптимально управлять ресурсами.
ну вот, пошли уточнения про вычислительные задачи а уж если надо оптимально управлять ресурсами то использовать C++ ето сам бог велел.

Х>>ещё раз про замыкания, в c++ ты можешь скопировать весь контекст (синтаксис [=]) и ето будет идентично по семантике с некоторыми лиспами, которые тоже копируют контекст, а не ссылки. Так с чем ты не согласен? то что С++ позволяет программисту оптимально оперировать контекстом? и там где не нужно копирование воспользоваться ссылкой? да, в случае ссылок программист должен учитывать время их жизни, но ето в мире с++ есстесственно, и от етого очевидно лямбды не меняют своего называния.
G>Мда..
G>Есть переменная на стеке, надо построить честное замыкание для лямбды. Время жизни лямбды больше текущего скоупа. Что С++ предлагает? Ничего.
да что же ты будешь делать, повторяю, три раза: контекст может копироваться, копироваться, копироваться.
т.е. в лямбду скопируется значение переменной на стеке
для закрепления:
копироваться может контекст
не только по ссылке а и по значению
копироваться
контекст
по значению
запомнил?

G>Читай выше и внимательнее.
читай выше и внимательнее

Х>>>>зайди в раздел .NET или .NET GUI и посмотри темы в которых люди кричат о недостаточной производительности, такое ощущение что избавившись от менеджмента памяти дотнетовцы теперь приседают в борьбе за производительность
G>>>Многие проблемы с производительностью от незнания. У меня саого программы на .NET тормозили когда я только начинал на нем писать. Теперь таких проблем нету.
Х>>я рад за тебя что у тебя нет проблемм с производительностью, а в коде над которым я работаю нет утечек памяти, и явные delete можно пересчитать по пальцам, и что?
G>И кто же память освобождает? shared_ptr, так они оверхед создают...
ух-хаха, я вообще не использую shared_ptr, представляешь? удивительно, да?

G>А вообще-то есть статистика. Так вот проблемы с утечками памяти в unmanaged появляют гораздо чаще проблем с производительностью в managed.
есть статистика, что на десктопах пользователей подавляющее большинство приложений — unmanaged, ето на мой взгляд самая лучшая статистика.

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

COF>Они позволяют реализовывать осмысленные стратегии управления ресурсами, в том числе отличными от памяти. На самом деле, это очевидно. Или наша цель догнать и перегнать хаскель, в том числе и по производительности, а ресурсы уж как-нибудь сами собой освободятся?
Что значит "осмысленные"?

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

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

COF>>>Ну так, а потом получается, что программы с GC страдают от утечек памяти. Кому сказать — не поверят
S>>Как связано отсутствие деструкторов и операторов присваивания в дотнете с утечками программ с GC?

COF>Они позволяют реализовывать осмысленные стратегии управления ресурсами, в том числе отличными от памяти.
Осмысленное в твоем понимании — ручное?

COF>>>Такое впечатление, что в ситуации "вам шашечки или ехать", дотнетчики уверенно выбирают шашечки
S>>Что, программы на дотнете ни разу не ездят впринципе?
COF>Медленно и печально
От чего такая уверенность?
Вот привели в пример какой-то пост, где с помощью WPF попытались нарисовать туеву хучу объектов. Интересно, на С++ аналогичное вообще заведется? (не говоря о том чтобы поехать)