Здравствуйте, MxMsk, Вы писали:
I>>Вот и еще одну обертку пришлось писать. MM>Может, вместо обертки стоит книжечки там почитать, документацию? Форумы к конце то концов!
Нет у чела времени изучать, кодить надо!
Здравствуйте, Kubyshev Andrey, Вы писали:
KA>Привет всем, KA>Лет 10 ездил на коробке. Думал нафига мне автомат, коробка это же "все под контролем". Пересел на автомат, на коробку обратно не хочу KA>СиПлюсПлюсил много лет, попробовал по-СиШарпить — обратно не хочется. НО ПРИДЕТСЯ! KA>
У нас архитектор на плюсах 13 лет писал, потом перешел на C# (уже год скоро). Говорит, на плюсы не вернется ни под каким предлогом
Здравствуйте, MTD, Вы писали:
MTD>Давай на конкретном примере, я тебе напишу код без проблемы цикличных ссылок или признаю, что ошибался?
Конкретный пример: в метод объекта передается функция, которая сохраняется для последующего использования. Как узнать, что эта примитивная операция не создает цикла?
Здравствуйте, MTD, Вы писали:
MTD>Здравствуйте, noone, Вы писали:
N>>Как решена проблема циклических ссылок?
MTD>shared_ptr/weak_ptr, но замечу, что циклические ссылки — проблема кривого дизайна
Обсуждается в другой подветке. Но ответ симптоматичный: чудес управления памятью без GC, похоже, не будет — будут велосипеды.
N>>Как происходит дефрагментация памяти?
MTD>Как обычно, что интересует?
Интересует как происходит дефрагментация свободной памяти программы. Впрочем, этот вопрос я сниму с повестки — к GC он имеет меньше отношения, чем к арифметике указателей.
Здравствуйте, noone, Вы писали:
MTD>>Давай на конкретном примере, я тебе напишу код без проблемы цикличных ссылок или признаю, что ошибался?
N>Конкретный пример: в метод объекта передается функция, которая сохраняется для последующего использования. Как узнать, что эта примитивная операция не создает цикла?
Это не пример, а демагогия. Я не говорил, что в С++ нельзя прострелить себе ногу, как раз это философия языка — меня можно использовать безопасно, но если ты такой умный, то действуй на свой страх и риск. Я говорил о том, что проблема циклических сылок — проблема дизайна. Или ты думаешь, что в языках со сборщиком мусора нет утечек памяти? Показать пример, как прострелить себе ногу?
Здравствуйте, noone, Вы писали:
MTD>>shared_ptr/weak_ptr, но замечу, что циклические ссылки — проблема кривого дизайна
N>Обсуждается в другой подветке. Но ответ симптоматичный: чудес управления памятью без GC, похоже, не будет — будут велосипеды.
Умные указатели — современный С++, а не велосипеды. То, что ты не знаешь язык, не говорит о его проблемах.
Здравствуйте, MTD, Вы писали:
MTD>Это не пример, а демагогия. Я не говорил, что в С++ нельзя прострелить себе ногу, как раз это философия языка — меня можно использовать безопасно, но если ты такой умный, то действуй на свой страх и риск. Я говорил о том, что проблема циклических сылок — проблема дизайна. Или ты думаешь, что в языках со сборщиком мусора нет утечек памяти? Показать пример, как прострелить себе ногу?
Покажи. Только без примера типа "в бессмысленной цепочке объектов, на которую ссылается забытое из-за legacy поле популярного объекта, непонятно почему приютилась ссылка на 20GB непонятной неудаляемой херни".
Здравствуйте, MTD, Вы писали:
N>>Как удобно — списал все неприятные случаи на "кривой дизайн" и доволен, что C++ разрешает справиться с остальными случаями.
N>>Я неоднократно встречался с ситуациями, когда естественным представлением предметной области является "сеть" объектов в памяти со многими связями. Например, такое типично в картографии, или в анализе структур человеческих связей.
MTD>Давай на конкретном примере, я тебе напишу код без проблемы цикличных ссылок или признаю, что ошибался?
Нет, давай вначале разберёмся с общим подходом. Ты настаиваешь на написании кода без циклических ссылок вообще? Или "без проблемы циклических ссылок"?
Здравствуйте, MTD, Вы писали:
F>>ну зачем же фантазировать? F>>shared_ptr — для использования такой тривиальной штуки, как шаблонный метод, требует регулярных кучерявых кастингов. не? MTD>Зачем в шаблонном методе shared_ptr?
предлагаешь вручную управлять памятью?
MTD>Кастинги — признак плохого дизайна.
upcasting или downcasting? или оба вместе?
MTD>Пример кода есть?
Здравствуйте, netch80, Вы писали:
MTD>>Давай на конкретном примере, я тебе напишу код без проблемы цикличных ссылок или признаю, что ошибался?
N>Нет, давай вначале разберёмся с общим подходом.
Здравствуйте, netch80, Вы писали:
N>Покажи. Только без примера типа "в бессмысленной цепочке объектов, на которую ссылается забытое из-за legacy поле популярного объекта, непонятно почему приютилась ссылка на 20GB непонятной неудаляемой херни".
Почему, нет? Неиспользуемы поля встречаются гораздо чаще циклических ссылок
Здравствуйте, MTD, Вы писали:
MTD>Умные указатели — современный С++, а не велосипеды. То, что ты не знаешь язык, не говорит о его проблемах.
Умные указатели — это костыль ("паттерн") из прошлого века для языков без автоматического управления памятью или встроенного подсчета ссылок. То, что современный С++ в отношение управления памятью находится в прошлом веке — точно не мои проблемы. Это же не я объявил отсутствие GC некой доблестью.
Здравствуйте, noone, Вы писали:
MTD>>Умные указатели — современный С++, а не велосипеды. То, что ты не знаешь язык, не говорит о его проблемах.
N>Умные указатели — это костыль ("паттерн") из прошлого века для языков без автоматического управления памятью или встроенного подсчета ссылок. То, что современный С++ в отношение управления памятью находится в прошлом веке — точно не мои проблемы. Это же не я объявил отсутствие GC некой доблестью.
Кстати, вопрос: Dispose — это костыль (пардон, "паттерн") или нет?
-- Пользователи не приняли программу. Всех пришлось уничтожить. --
Здравствуйте, noone, Вы писали:
MTD>>Умные указатели — современный С++, а не велосипеды. То, что ты не знаешь язык, не говорит о его проблемах.
N>Умные указатели — это костыль ("паттерн") из прошлого века для языков без автоматического управления памятью или встроенного подсчета ссылок. То, что современный С++ в отношение управления памятью находится в прошлом веке — точно не мои проблемы. Это же не я объявил отсутствие GC некой доблестью.
Ты все перепутал — GC паттерн из прошлого века, тормозной и ненужный.
Здравствуйте, MTD, Вы писали:
MTD>Это не пример, а демагогия.
Не понял, где здесь демагогия. Сохранение callback (он же listener, он же delegate) — задача тривиальная и часто встречающаяся в прикладных программах.
MTD>Я не говорил, что в С++ нельзя прострелить себе ногу, как раз это философия языка — меня можно использовать безопасно, но если ты такой умный, то действуй на свой страх и риск.
Причем здесь C++? Ветка про подсчет ссылок.
MTD>Я говорил о том, что проблема циклических сылок — проблема дизайна.
Нет, это проблема подсчета ссылок — простейшие вещи ведут к утечке памяти. Почему я должен уродовать архитектуру только для того, чтобы натянуть ее на технологию с неподходящей семантикой? Это ведь не бесплатно. А потом тратить время на подчистку утечек за менее опытными коллегами. Почему просто не взять язык с GC? Потому что MTD уверен — без этого легко обойтись. Вот я и жду ответа.
MTD>Или ты думаешь, что в языках со сборщиком мусора нет утечек памяти? Показать пример, как прострелить себе ногу?
В начале ветки я задал вопрос: как конкретные проблемы, решенные GC, могут быть решены без него. То, что GC это не райское наслаждение, мне доказывать не нужно.
Здравствуйте, MTD, Вы писали:
MTD>>>Зачем в шаблонном методе shared_ptr? F>>предлагаешь вручную управлять памятью? MTD>Нет. shared_ptr реально нужен в 1 случае из 200.
как тогда предлагаешь управлять памятью?
MTD>>>Кастинги — признак плохого дизайна. F>>upcasting или downcasting? или оба вместе? MTD>Везде где надо что-то привести вручную.
т.е. shared_ptr — признак плохого дизайна? кхм
MTD>>>Пример кода есть? F>>не знаешь, как делается шаблонный метод? MTD>Меня интересует твоя реализация.
Здравствуйте, MTD, Вы писали:
MTD>Ты все перепутал — GC паттерн из прошлого века, тормозной и ненужный.
Да фиг с ним, что тормозной. Плохо, что он бывает внезапно тормозной.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, neFormal, Вы писали:
MTD>>Нет. shared_ptr реально нужен в 1 случае из 200.
F>как тогда предлагаешь управлять памятью?
Открой для себя контейнеры.
MTD>>Везде где надо что-то привести вручную. F>т.е. shared_ptr — признак плохого дизайна? кхм
Странный вывод. Можешь привести ход рассуждений?
MTD>>Меня интересует твоя реализация. F>моя вполне классическая.
Ну так приведи, а не отмазывайся.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
