Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>>Нет такой ссылки, потому что компилятор от MS ещё не продаётся. VD>>Значит и обсуждать не чего.
ГВ>Так и не обсуждай. Тебя кто-то заставляет?
Обсуждал, ты а теперь откровенно гонишь. Учись признавать свою неправоту.
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, gandjustas, Вы писали:
Х>>здесь поподробней пожалуйста, что имеется ввиду? G>Стандартные аллокаторы в С++ требуют прохода по списку свободных блоков памяти при выделении\освобождении, эта операция имеет алгоритмическую сложность O(n). При интенсивных операциях выделения\освобождения работает очеень медленно.
Ключевое слово — пул.
G>Кроме того проход по списку непотокобезопасен, поэтому требуются особые приседания чтобы стандартный аллокатор нормально заработал в многопоточном окружении.
Это что-то новенькое. Стандартные аллокаторы как раз вполне работают в многопоточном окружении.
G>Ты прочитай 3 предыдущие страницы. Нормальные лямбды подразумевают лексические замыкания, которых нету и не будет в С++.
Повторение тезиса, как известно, поднимает его истинность в геометрической прогрессии.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
ГВ>>>А что за недостатки (кроме синхронного подсчёта количества ссылок)? G>>сам по себе подстчет ссылок — не лучшый механизи. Дает оверхед по памяти и по быстродействию, не разруливает циклы, непотокобезопасны. G>>auto_ptr с передачей владения не намного лучше обычных указателей, при этом надо ими пользоваться очень осторожно и хорошо понимать что происходит "под капотом".
ГВ>OK, принято. ИМХО, самый серьёзный недостаток такого способа — потенциальные заморочки с циклическими зависимостями. Ну что же, действительно, опциональный (библиотечный) GC иной раз не помешал бы. В принципе — не помешал бы. Другое дело, что острота потребности в GC, ИМХО, невероятно преувеличена. Вот тут, честно тебе скажу, доказать ты её (острую потребность) не сможешь. Потому что придётся доказывать, исходя из субъективных моментов, а субъективно как раз таких проблем нет — C++-ники привыкли управлять своими объектами и им это вполне удаётся. Хорошим C++-никам — удаётся, а кто не умеет — тот плохой C++-ник, и к его мнению не особо прислушиваются.
Как раз таки привычки субъективны. А потребность в высокоуровневых языках в большенстве задач очень объективна.
Но при этом существует достаточно много программистов на С++ со своим субъективным мнением.
ГВ>ИМХО, потому про GC хоть и поговаривают, но не особо.
Еще раз. Не получится на C++ сделать CG с характеристиками, близкими к .NETовскому.
Сам язык должен быть рассчитан на работу GC.
Практически любая реализация GC на C++ будет вносить достаточно большой оверхед чтобы отказаться от его использования.
Здравствуйте, Геннадий Васильев, Вы писали:
Х>>>здесь поподробней пожалуйста, что имеется ввиду? G>>Стандартные аллокаторы в С++ требуют прохода по списку свободных блоков памяти при выделении\освобождении, эта операция имеет алгоритмическую сложность O(n). При интенсивных операциях выделения\освобождения работает очеень медленно.
ГВ>Ключевое слово — пул.
Вы только что узнали новое слово и решили вставить его, чтоб казаться умным?
Здравствуйте, VladD2, Вы писали:
ГВ>>Так и не обсуждай. Тебя кто-то заставляет? VD>Обсуждал, ты а теперь откровенно гонишь. Учись признавать свою неправоту.
Иными словами, сказать тебе больше нечего.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
Х>>>здесь поподробней пожалуйста, что имеется ввиду? G>>Стандартные аллокаторы в С++ требуют прохода по списку свободных блоков памяти при выделении\освобождении, эта операция имеет алгоритмическую сложность O(n). При интенсивных операциях выделения\освобождения работает очеень медленно. ГВ>Ключевое слово — пул.
Угу, очередной "закат солнца вручную". Кроме того с пулом возникают дополнительные проблемы управления временем жизни.
G>>Кроме того проход по списку непотокобезопасен, поэтому требуются особые приседания чтобы стандартный аллокатор нормально заработал в многопоточном окружении. ГВ>Это что-то новенькое. Стандартные аллокаторы как раз вполне работают в многопоточном окружении.
Угу, но работают медленно. Даже при однопоточном выделении. Блокировки небесплатные.
Здравствуйте, criosray, Вы писали:
ГВ>>Ключевое слово — пул. C>Вы только что узнали новое слово и решили вставить его, чтоб казаться умным?
Конечно. Я из этой дискуссии столько нового почерпнул — ты не поверишь! Столько новых слов, столько новых идей! Люблю с умными людьми общаться — сразу умнее становлюсь.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
ГВ>>Ключевое слово — пул. G>Угу, очередной "закат солнца вручную". Кроме того с пулом возникают дополнительные проблемы управления временем жизни.
Это какие такие проблемы? Что объекты должны быть уничтожены до уничтожения самого пула? Так это — то же самое, что и общее предотвращение утечек памяти.
G>>>Кроме того проход по списку непотокобезопасен, поэтому требуются особые приседания чтобы стандартный аллокатор нормально заработал в многопоточном окружении. ГВ>>Это что-то новенькое. Стандартные аллокаторы как раз вполне работают в многопоточном окружении. G>Угу, но работают медленно. Даже при однопоточном выделении. Блокировки небесплатные.
Ты уж определись: работают стандартные аллокаторы в многопоточном окружении или нет.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, VladD2, Вы писали:
VD>А можно узнать, решениями каких задач ты занимаешься на С++?
Можно, в данный момент ето десктопная GIS.
В свою очередь можно узнать, какие задачи ты решаешь на C#?
Здравствуйте, 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 совсем органично вплетался в язык, сам язык должен быть изначально спроектирован для использования GC.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
G>Стандартные аллокаторы в С++ требуют прохода по списку свободных блоков памяти при выделении\освобождении, эта операция имеет алгоритмическую сложность O(n). При интенсивных операциях выделения\освобождения работает очеень медленно.
для интенсивных операций существует пулы/арены G>Кроме того проход по списку непотокобезопасен, поэтому требуются особые приседания чтобы стандартный аллокатор нормально заработал в многопоточном окружении.
ну ето просто неправда
Х>>>>в случае с с++ лямбдами исполнено на 100%, G>>>На 200%, лямбд просто нету Есть только жалкое подобие. Х>>может ты найдёшь определение lambda в интернет и перестанешь нести ахинею? G>Ты прочитай 3 предыдущие страницы. Нормальные лямбды подразумевают лексические замыкания, которых нету и не будет в С++.
во-первых: лямбды не подразумевают замыкания, ето замыкания подразумевают лямбды.
во-вторых: лексическое замыкание есть, прочитай теперь ты 3 предыдущие страницы.
Х>>да уж, дотнет действительно замазка для мозга. гц, метаданные, промежуточный код + jit, бесчисленные проверки кода на сейфанутость — всё ето есть даже тогда когда тебе етого не нужно, и ето всё в таком случае — не нужный оверхед. G>Не разводи демагогию, давай факты.
зайди в раздел .NET или .NET GUI и посмотри темы в которых люди кричат о недостаточной производительности, такое ощущение что избавившись от менеджмента памяти дотнетовцы теперь приседают в борьбе за производительность
Здравствуйте, Хвост, Вы писали:
Х>зайди в раздел .NET или .NET GUI и посмотри темы в которых люди кричат о недостаточной производительности, такое ощущение что избавившись от менеджмента памяти дотнетовцы теперь приседают в борьбе за производительность
Что за темы?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
ГВ>>>Ключевое слово — пул. G>>Угу, очередной "закат солнца вручную". Кроме того с пулом возникают дополнительные проблемы управления временем жизни.
ГВ>Это какие такие проблемы? Что объекты должны быть уничтожены до уничтожения самого пула? Так это — то же самое, что и общее предотвращение утечек памяти.
Опять возвращаемся к ручному управлнию памятью, никаких shred_ptr и прочего.
G>>>>Кроме того проход по списку непотокобезопасен, поэтому требуются особые приседания чтобы стандартный аллокатор нормально заработал в многопоточном окружении. ГВ>>>Это что-то новенькое. Стандартные аллокаторы как раз вполне работают в многопоточном окружении. G>>Угу, но работают медленно. Даже при однопоточном выделении. Блокировки небесплатные. ГВ>Ты уж определись: работают стандартные аллокаторы в многопоточном окружении или нет.
Раьотают, но медленно
Здравствуйте, MxKazan, Вы писали:
Х>>зайди в раздел .NET или .NET GUI и посмотри темы в которых люди кричат о недостаточной производительности, такое ощущение что избавившись от менеджмента памяти дотнетовцы теперь приседают в борьбе за производительность MK>Что за темы?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, gandjustas, Вы писали:
ГВ>>Это какие такие проблемы? Что объекты должны быть уничтожены до уничтожения самого пула? Так это — то же самое, что и общее предотвращение утечек памяти. G>Опять возвращаемся к ручному управлнию памятью, никаких shred_ptr и прочего.
Почему? Самое обыкновенное управление модулями в программе на C++. В числе прочих, фаза завершения работы модуля может включать и очистку статических (глобальных) указателей.
G>>>>>Кроме того проход по списку непотокобезопасен, поэтому требуются особые приседания чтобы стандартный аллокатор нормально заработал в многопоточном окружении. ГВ>>>>Это что-то новенькое. Стандартные аллокаторы как раз вполне работают в многопоточном окружении. G>>>Угу, но работают медленно. Даже при однопоточном выделении. Блокировки небесплатные. ГВ>>Ты уж определись: работают стандартные аллокаторы в многопоточном окружении или нет. G>Раьотают, но медленно
То есть, "нормальная" в твоей терминологии работа — это работа без блокировок, я прав?
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Хвост, Вы писали:
Х>Здравствуйте, gandjustas, Вы писали:
G>>Стандартные аллокаторы в С++ требуют прохода по списку свободных блоков памяти при выделении\освобождении, эта операция имеет алгоритмическую сложность O(n). При интенсивных операциях выделения\освобождения работает очеень медленно. Х>для интенсивных операций существует пулы/арены
А если у тебя вся программа состоит из таких нтенсивных операций, например высоконагруженный сервер?
G>>Кроме того проход по списку непотокобезопасен, поэтому требуются особые приседания чтобы стандартный аллокатор нормально заработал в многопоточном окружении. Х>ну ето просто неправда
Наверное неправльно понял. Приседания требуются в самом аллокаторе, кто снижает производительность.
Х>>>>>в случае с с++ лямбдами исполнено на 100%, G>>>>На 200%, лямбд просто нету Есть только жалкое подобие. Х>>>может ты найдёшь определение lambda в интернет и перестанешь нести ахинею? G>>Ты прочитай 3 предыдущие страницы. Нормальные лямбды подразумевают лексические замыкания, которых нету и не будет в С++. Х>во-первых: лямбды не подразумевают замыкания, ето замыкания подразумевают лямбды.
Источник этого бреда в студию.
Х>во-вторых: лексическое замыкание есть, прочитай теперь ты 3 предыдущие страницы.
Нету. Можно сымитировать подобие лексических замыканий причем со значительными ограничениями.
Х>>>да уж, дотнет действительно замазка для мозга. гц, метаданные, промежуточный код + jit, бесчисленные проверки кода на сейфанутость — всё ето есть даже тогда когда тебе етого не нужно, и ето всё в таком случае — не нужный оверхед. G>>Не разводи демагогию, давай факты. Х>зайди в раздел .NET или .NET GUI и посмотри темы в которых люди кричат о недостаточной производительности, такое ощущение что избавившись от менеджмента памяти дотнетовцы теперь приседают в борьбе за производительность
Многие проблемы с производительностью от незнания. У меня саого программы на .NET тормозили когда я только начинал на нем писать. Теперь таких проблем нету.
Здравствуйте, Хвост, Вы писали:
MK>>Что за темы? Х>тебе дать ссылку на тему которую завёл ты сам?
Я, конечно, предполагал, что ты так можешь облажаться, но что Геннадий туда же... Это прямо как про боксинг!
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Здравствуйте, gandjustas, Вы писали:
ГВ>>>Это какие такие проблемы? Что объекты должны быть уничтожены до уничтожения самого пула? Так это — то же самое, что и общее предотвращение утечек памяти. G>>Опять возвращаемся к ручному управлнию памятью, никаких shred_ptr и прочего.
ГВ>Почему? Самое обыкновенное управление модулями в программе на C++. В числе прочих, фаза завершения работы модуля может включать и очистку статических (глобальных) указателей.
Ох ё....
G>>>>>>Кроме того проход по списку непотокобезопасен, поэтому требуются особые приседания чтобы стандартный аллокатор нормально заработал в многопоточном окружении. ГВ>>>>>Это что-то новенькое. Стандартные аллокаторы как раз вполне работают в многопоточном окружении. G>>>>Угу, но работают медленно. Даже при однопоточном выделении. Блокировки небесплатные. ГВ>>>Ты уж определись: работают стандартные аллокаторы в многопоточном окружении или нет. G>>Раьотают, но медленно
ГВ>То есть, "нормальная" в твоей терминологии работа — это работа без блокировок, я прав?
Правильная работа — это когда не надо думать выделять память или нет.
Самое обыкновенное управление модулями в программе на C++. В числе прочих, фаза завершения работы модуля может включать и очистку статических (глобальных) указателей.