Здравствуйте, MxKazan, Вы писали:
MK>>>Что за темы? Х>>тебе дать ссылку на тему которую завёл ты сам? MK>Я, конечно, предполагал, что ты так можешь облажаться, но что Геннадий туда же... Это прямо как про боксинг!
и где же здесь лажа? что просил то и получил.
кстати про боксинг, будь добр расскажи, какой магией структуры на стеке, которые являются контекстом лямбды, продляют свою жизнь при возврате лямбды из метода?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
ГВ>>>OK, принято. ИМХО, самый серьёзный недостаток такого способа — потенциальные заморочки с циклическими зависимостями. Ну что же, действительно, опциональный (библиотечный) GC иной раз не помешал бы. В принципе — не помешал бы. Другое дело, что острота потребности в GC, ИМХО, невероятно преувеличена. Вот тут, честно тебе скажу, доказать ты её (острую потребность) не сможешь. Потому что придётся доказывать, исходя из субъективных моментов, а субъективно как раз таких проблем нет — C++-ники привыкли управлять своими объектами и им это вполне удаётся. Хорошим C++-никам — удаётся, а кто не умеет — тот плохой C++-ник, и к его мнению не особо прислушиваются. G>>Как раз таки привычки субъективны. А потребность в высокоуровневых языках в большенстве задач очень объективна. ГВ>Приехали. C++ — высокоуровневый язык. Или вы хотите поговорить о DSL? Ну давай, поговорим про DSL.
С++ очень низкоуровневый по сравнению с современными языками.
G>>Но при этом существует достаточно много программистов на С++ со своим субъективным мнением. ГВ>Если мнения этих программистов хватает, чтобы решать поставленные задачи, значит, потребность в языках местами преувеличена, т.е., не всегда объективна. Сам понимаешь, материя "потребности" тонкая, весьма зависимая от "интеграла по субъективным суждениям".
Ну ты страшный бред говоришь. Это примерно как думать что не нужны машины, потому что лошадей хватает решать задачи.
ГВ>>>ИМХО, потому про GC хоть и поговаривают, но не особо. G>>Еще раз. Не получится на C++ сделать CG с характеристиками, близкими к .NETовскому. G>>Сам язык должен быть рассчитан на работу GC. G>>Практически любая реализация GC на C++ будет вносить достаточно большой оверхед чтобы отказаться от его использования. ГВ>Не совсем так. Дело в том, что GC для C++ не должен решать задачи управления абсолютно всеми объектами и никто ничего такого и не предлагает. Но для каких-то отдельных моментов он вполне может оказаться приемлемым решением, лучшим, чем reference counting. Ключевое слово: "какие-то отдельные моменты".
Ну а тепереь давай точнее. Как будет происходить разделение между управляемыми GC объектами и остальными? Какие это даст преимущества?
Здравствуйте, Хвост, Вы писали:
Х>Здравствуйте, MxKazan, Вы писали:
MK>>>>Что за темы? Х>>>тебе дать ссылку на тему которую завёл ты сам? MK>>Я, конечно, предполагал, что ты так можешь облажаться, но что Геннадий туда же... Это прямо как про боксинг! Х>и где же здесь лажа? что просил то и получил. Х>кстати про боксинг, будь добр расскажи, какой магией структуры на стеке, которые являются контекстом лямбды, продляют свою жизнь при возврате лямбды из метода?
Это и называется лексическим замыканием
На C++ (даже с новым стандартом) такое повторить сможешь?
Здравствуйте, gandjustas, Вы писали:
G>>>Стандартные аллокаторы в С++ требуют прохода по списку свободных блоков памяти при выделении\освобождении, эта операция имеет алгоритмическую сложность O(n). При интенсивных операциях выделения\освобождения работает очеень медленно. Х>>для интенсивных операций существует пулы/арены G>А если у тебя вся программа состоит из таких нтенсивных операций, например высоконагруженный сервер?
даа, вся программа состоит из аллокаций в хипе, такую ещё поискать надо, а как же твои незабвенные 10% кода отнимают 90% ресурсов? или ето не распространяется на высоконагруженные сервера?
G>>>Кроме того проход по списку непотокобезопасен, поэтому требуются особые приседания чтобы стандартный аллокатор нормально заработал в многопоточном окружении. Х>>ну ето просто неправда G>Наверное неправльно понял. Приседания требуются в самом аллокаторе, кто снижает производительность.
что-то я совсем запутался, кто и где приседает.
Х>>>>>>в случае с с++ лямбдами исполнено на 100%, G>>>>>На 200%, лямбд просто нету Есть только жалкое подобие. Х>>>>может ты найдёшь определение lambda в интернет и перестанешь нести ахинею? G>>>Ты прочитай 3 предыдущие страницы. Нормальные лямбды подразумевают лексические замыкания, которых нету и не будет в С++. Х>>во-первых: лямбды не подразумевают замыкания, ето замыкания подразумевают лямбды. G>Источник этого бреда в студию.
какого бреда? лямбда — анонимная функция
замыкание — функция знающая о контексте вызывающей функции
возможно я погорячился что замыкания подразумевают лямбды, но в большинстве языков ето так, с чем ты не согласен собственно?
ещё раз про замыкания, в c++ ты можешь скопировать весь контекст (синтаксис [=]) и ето будет идентично по семантике с некоторыми лиспами, которые тоже копируют контекст, а не ссылки. Так с чем ты не согласен? то что С++ позволяет программисту оптимально оперировать контекстом? и там где не нужно копирование воспользоваться ссылкой? да, в случае ссылок программист должен учитывать время их жизни, но ето в мире с++ есстесственно, и от етого очевидно лямбды не меняют своего называния.
Х>>во-вторых: лексическое замыкание есть, прочитай теперь ты 3 предыдущие страницы. G>Нету. Можно сымитировать подобие лексических замыканий причем со значительными ограничениями.
ещё раз, где иммитация? в чём иммитация?
Х>>зайди в раздел .NET или .NET GUI и посмотри темы в которых люди кричат о недостаточной производительности, такое ощущение что избавившись от менеджмента памяти дотнетовцы теперь приседают в борьбе за производительность G>Многие проблемы с производительностью от незнания. У меня саого программы на .NET тормозили когда я только начинал на нем писать. Теперь таких проблем нету.
я рад за тебя что у тебя нет проблемм с производительностью, а в коде над которым я работаю нет утечек памяти, и явные delete можно пересчитать по пальцам, и что?
Здравствуйте, MxKazan, Вы писали:
MK>Я, конечно, предполагал, что ты так можешь облажаться, но что Геннадий туда же... Это прямо как про боксинг!
Шутки-шутками, но если заглянуть в .NET GUI, то там прямо таки несколько активных топиков — про производительность. Однако!
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
MK>>Я, конечно, предполагал, что ты так можешь облажаться, но что Геннадий туда же... Это прямо как про боксинг!
ГВ>Шутки-шутками, но если заглянуть в .NET GUI, то там прямо таки несколько активных топиков — про производительность. Однако!
Здравствуйте, gandjustas, Вы писали:
ГВ>>Почему? Самое обыкновенное управление модулями в программе на C++. В числе прочих, фаза завершения работы модуля может включать и очистку статических (глобальных) указателей. G>Ох ё....
А по сути?
ГВ>>То есть, "нормальная" в твоей терминологии работа — это работа без блокировок, я прав? G>Правильная работа — это когда не надо думать выделять память или нет.
Понятно. Всё, что не C# — неправильно. Так бы сразу и сказал.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, MxKazan, Вы писали: MK>>Я, конечно, предполагал, что ты так можешь облажаться, но что Геннадий туда же... Это прямо как про боксинг! ГВ>Шутки-шутками, но если заглянуть в .NET GUI, то там прямо таки несколько активных топиков — про производительность. Однако!
Ага. Только потом выясняется, что в обеих программисты создают по 10 тысяч пользовательских элементов, в одной это длиться 1-4 секунды, а в другой тормоза обнаруживаются в нативном(!) слое отрисовки. Только чтобы это понять, надо хотя-бы немного шарить в WPF, а не вестись на название тем. Кстати, еще упоминалось про тормоза в ветке .NET (не GUI). Не поделишься ссылками?
Здравствуйте, Хвост, Вы писали:
Х>кстати про боксинг, будь добр расскажи, какой магией структуры на стеке, которые являются контекстом лямбды, продляют свою жизнь при возврате лямбды из метода?
Легко. Эти структуры размещаются не на стеке, а в полях класса, который и лямбду оборачивает.
Здравствуйте, Хвост, Вы писали:
Х>кстати про боксинг, будь добр расскажи, какой магией структуры на стеке, которые являются контекстом лямбды, продляют свою жизнь при возврате лямбды из метода?
Структуры, являющиеся контекстом лямбды изначально расположены не на стеке, а в хипе вместе со всем контекстом лямбды. Потому боксинга здесь нет.
Здравствуйте, MxKazan, Вы писали:
Х>>кстати про боксинг, будь добр расскажи, какой магией структуры на стеке, которые являются контекстом лямбды, продляют свою жизнь при возврате лямбды из метода? MK>Легко. Эти структуры размещаются не на стеке, а в полях класса, который и лямбду оборачивает.
логично, в с++ вероятно похожая схема
Здравствуйте, samius, Вы писали:
Х>>кстати про боксинг, будь добр расскажи, какой магией структуры на стеке, которые являются контекстом лямбды, продляют свою жизнь при возврате лямбды из метода? MK>Легко. Эти структуры размещаются не на стеке, а в полях класса, который и лямбду оборачивает.
Х>>кстати про боксинг, будь добр расскажи, какой магией структуры на стеке, которые являются контекстом лямбды, продляют свою жизнь при возврате лямбды из метода? S>Структуры, являющиеся контекстом лямбды изначально расположены не на стеке, а в хипе вместе со всем контекстом лямбды. Потому боксинга здесь нет.
эээ, ребят, вы таки определитесь как оно работает
) Х>Тут дотнет во всей красе, и тормозящий интерфейс, и утечки памяти, вобщем всё лучшее — детям :)))
Да уж, такое впечатление что дотнетчики живут в каком-то виртуальном мире, навеянном рекламными проспектами — в мире где нет утечек памяти, где программы летают, а критерием хорошести языка является то, насколько он поддерживает лямбды :) В конце-концов, ну не было в C++ лямбд — ну и черт с ними, вполне можно без них прожить. Что народ к ним привязался? А вот в C# нет деструкторов и переопределения операторов присваивания, например. Я конечно понимаю, что если чего-то нет в текущей версии C# — это не нужно, а если чего-то нет в C++ — это плохой дизайн языка, но все же :)
Здравствуйте, Хвост, Вы писали:
Х>>>кстати про боксинг, будь добр расскажи, какой магией структуры на стеке, которые являются контекстом лямбды, продляют свою жизнь при возврате лямбды из метода? S>>Структуры, являющиеся контекстом лямбды изначально расположены не на стеке, а в хипе вместе со всем контекстом лямбды. Потому боксинга здесь нет. Х>эээ, ребят, вы таки определитесь как оно работает
То, что структура лежит в хипе, не означает что она отбоксирована. Может хоть немного сделаешь вид, что понимаешь о чем пишешь?
Здравствуйте, Хвост, Вы писали:
Х>Здравствуйте, MxKazan, Вы писали:
MK>>Легко. Эти структуры размещаются не на стеке, а в полях класса, который и лямбду оборачивает. Х>логично, в с++ вероятно похожая схема
Судя по описанию новшеств в C++0x, ссылку на которое давал ГВ, схема в C++ невероятно не похожа на дотнетовскую.
Здравствуйте, MxKazan, Вы писали:
MK>Здравствуйте, Хвост, Вы писали:
Х>>>>кстати про боксинг, будь добр расскажи, какой магией структуры на стеке, которые являются контекстом лямбды, продляют свою жизнь при возврате лямбды из метода? S>>>Структуры, являющиеся контекстом лямбды изначально расположены не на стеке, а в хипе вместе со всем контекстом лямбды. Потому боксинга здесь нет. Х>>эээ, ребят, вы таки определитесь как оно работает MK>То, что структура лежит в хипе, не означает что она отбоксирована. Может хоть немного сделаешь вид, что понимаешь о чем пишешь?
погоди ерепенится, прочтя твоё сообщение я понял что структура изначально таки лежит на стеке, но в момент вызова лямбды она копируется в поле лямбды, своё же сообщение я написал в ответ на сообщение samius'а, в котором написано что структуры, попадающие в scope лямбды никогда не лежат на стеке, так как всё-таки верно? если верно второе то ето вообще удивительно, получается что там где в C# вызывается лямбда стековых структур не может быть в принципе, а ето просто неимоверный оверхед.
Здравствуйте, gandjustas, Вы писали:
G>>>Как раз таки привычки субъективны. А потребность в высокоуровневых языках в большенстве задач очень объективна. ГВ>>Приехали. C++ — высокоуровневый язык. Или вы хотите поговорить о DSL? Ну давай, поговорим про DSL. G>С++ очень низкоуровневый по сравнению с современными языками.
У меня дежа-вю. Это уже было и совсем недавно.
G>>>Но при этом существует достаточно много программистов на С++ со своим субъективным мнением. ГВ>>Если мнения этих программистов хватает, чтобы решать поставленные задачи, значит, потребность в языках местами преувеличена, т.е., не всегда объективна. Сам понимаешь, материя "потребности" тонкая, весьма зависимая от "интеграла по субъективным суждениям". G>Ну ты страшный бред говоришь. Это примерно как думать что не нужны машины, потому что лошадей хватает решать задачи.
Дык. Были бы машины. Больше похоже на замену одних лошадей чуть-чуть более другими.
ГВ>>Не совсем так. Дело в том, что GC для C++ не должен решать задачи управления абсолютно всеми объектами и никто ничего такого и не предлагает. Но для каких-то отдельных моментов он вполне может оказаться приемлемым решением, лучшим, чем reference counting. Ключевое слово: "какие-то отдельные моменты". G>Ну а тепереь давай точнее. Как будет происходить разделение между управляемыми GC объектами и остальными? Какие это даст преимущества?
Тут надо подумать, быстро не отвечу. Преимущества, по идее, должны быть в меньшем количестве lock (неизбежен при подсчёте ссылок) и соответственно — в меньшем количестве сбросов кэша процессора. Ну и конечно — в решении проблемы с циклическими ссылками.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Хвост, Вы писали:
Х>погоди ерепенится, прочтя твоё сообщение я понял что структура изначально таки лежит на стеке, но в момент вызова лямбды она копируется в поле лямбды, своё же сообщение я написал в ответ на сообщение samius'а, в котором написано что структуры, попадающие в scope лямбды никогда не лежат на стеке, так как всё-таки верно? Замкнутые структуры размещаются в полях класса.
Х>если верно второе то ето вообще удивительно, получается что там где в C# вызывается лямбда стековых структур не может быть в принципе, а ето просто неимоверный оверхед.
Ты так шутишь или взаправду считаешь, что 30-40 байт — это НЕИМОВЕРНЫЙ ОВЕРХЕД!?!?!?
Есть только жалкое подобие.
Самое обыкновенное управление модулями в программе на C++. В числе прочих, фаза завершения работы модуля может включать и очистку статических (глобальных) указателей.
