Вот, допустим, приходится вам доработать некую прогу. А там при открытии окна настроек, которое открывается не часто а может вообще никогда — немного подтекает. Ну примерно по 100 кб. при каждом открытии.
Стали бы вы на этом заострять внимание или хрен с ним?
Как вы вообще относитесь к утечкам — снисходительно или ни байта утечек?
Здравствуйте, Нomunculus, Вы писали:
Н>Ни байта утечек, конечно. Не ради утечек. А потому что ты уже потерял контроль над программой и это чревато гораздо большими проблемами.
Но а вообще по вашему опыту — насколько часто утечки в популярных программах?
Вот взять Хром, на который жалуются. Он реально течет или там просто кеш выделяется оно все потом само со временем очистится?
Здравствуйте, Shmj, Вы писали:
S>Но а вообще по вашему опыту — насколько часто утечки в популярных программах?
Не знай, не дебажил популярные программы. Если прога забивает память и тормозит — я просто ей не пользуюсь, не выясняю утечки это или нет.
S>Вот взять Хром, на который жалуются. Он реально течет или там просто кеш выделяется оно все потом само со временем очистится?
Ну а если так, то что? Это повод подражать им в плохом?
Здравствуйте, Нomunculus, Вы писали:
S>>Вот взять Хром, на который жалуются. Он реально течет или там просто кеш выделяется оно все потом само со временем очистится? Н>Ну а если так, то что? Это повод подражать им в плохом?
Пока ты будешь байты считать — они выпустят новую версию и завоюют рынок.
Здравствуйте, Shmj, Вы писали:
S>Пока ты будешь байты считать — они выпустят новую версию и завоюют рынок.
Кто "они"? Хром. Я работаю абсолютно в другой области.
И да, я предпочитаю качество своей работы. Взять хотя бы игры. Есть огромные игры с огромными бюджетами, которые текут, зависают, падают. И да, гребут бабло лопатой, несмотря на то, что все на них плюются.
А есть маленькие нишевые игры, вылизанные, продуманные, фанаты обсуждают их и ждут новые версии. Хотя да, лопатой бабло не гребут.
Так вот — я предпочитаю быть ближе ко второй группе разработчиков, чем к первой.
Ты во многих темах говоришь, что деньги — это критерий чего-то. Это примитивизация мира. Потому что деньги — это циферьки и их легко сравнить. Но в реальности — деньги абсолютно не критерий.
Все баги не исправишь. Всегда есть приоритеты. По крайней мере я других проектов пока не видел. Небольшие утечки памяти на мой взгляд это из разряда низкоприоритетных багов. Я бы исправлял все баги, я перфекционист, но бизнес на это может смотреть по-другому.
Здравствуйте, vsb, Вы писали:
vsb>Все баги не исправишь. Всегда есть приоритеты. По крайней мере я других проектов пока не видел. Небольшие утечки памяти на мой взгляд это из разряда низкоприоритетных багов. Я бы исправлял все баги, я перфекционист, но бизнес на это может смотреть по-другому.
Здравствуйте, so5team, Вы писали:
vsb>>Все баги не исправишь. Всегда есть приоритеты. По крайней мере я других проектов пока не видел. Небольшие утечки памяти на мой взгляд это из разряда низкоприоритетных багов. Я бы исправлял все баги, я перфекционист, но бизнес на это может смотреть по-другому.
S>Так вы же, вроде бы, и на C++ не пишете?
Иногда пишу. В жаве утечки памяти тоже случаются. А чем специфичны утечки памяти на С++?
Здравствуйте, vsb, Вы писали:
vsb>Иногда пишу. В жаве утечки памяти тоже случаются. А чем специфичны утечки памяти на С++?
По сравнению с чистым Си, про использование которого вы недавно в другой теме говорили, в C++ есть механизм(ы) для простого (по отношению к Си) и эффективного управления памятью. Если такие механизмы используются, а память в C++ном коде все равно течет, то программа явно работает не так (тут Нomunculus совершенно прав
). А раз программа работает не так, то может течь и все остальное, а может быть и еще чего хуже (отсутствие обработки каких-то ситуаций или неправильная их обработка, к примеру).
Так что толерантное отношение к утечкам памяти в C++ коде удивляет. Можно это простить, когда такое случается во время аврала, записывается в технический долг и затем исправляется. Но это исключительные случаи, имхо.
Здравствуйте, Shmj, Вы писали:
S>Вот, допустим, приходится вам доработать некую прогу. А там при открытии окна настроек, которое открывается не часто а может вообще никогда — немного подтекает. Ну примерно по 100 кб. при каждом открытии. S>Стали бы вы на этом заострять внимание или хрен с ним? S>Как вы вообще относитесь к утечкам — снисходительно или ни байта утечек?
К утечкам отношусь отрицательно, конечно же, но и в "подтекающую" программу не полезу, очертя голову. Я считаю, что в программах, написаных с какой-то самой элементарной культурой, утечки памяти исключены. А если это не так, то эта программа подобна неразорвавшемуся снаряду и без саперов ее лучше не трогать.
Здравствуйте, Shmj, Вы писали:
S>Вот, допустим, приходится вам доработать некую прогу. А там при открытии окна настроек, которое открывается не часто а может вообще никогда — немного подтекает. Ну примерно по 100 кб. при каждом открытии. S>Стали бы вы на этом заострять внимание или хрен с ним?
Однажды я устроился работать в контору и моим первым заданием было: вот тебе программа, твоя задача — устранить все утечки памяти. Завернул все голые указатели в смарт объекты и утечек не стало.
S>Как вы вообще относитесь к утечкам — снисходительно или ни байта утечек?
Так это не программисту решать, а пользователям. Вон — JavaScript течёт почти во всех браузерах, но правят баги только если память начинает утекать слишком быстро, т.е. быстрее, чем закончится работа пользователя в браузере.
А есть программы, которые работают месяцами и годами — в них даже байтовые утечки не допустимы.
А ещё есть программы, работа которых связана с безопасностью людей, для них вообще по нормам часто запрещается динамический заказ памяти.
Здравствуйте, Shmj, Вы писали:
S>Вот, допустим, приходится вам доработать некую прогу. А там при открытии окна настроек, которое открывается не часто а может вообще никогда — немного подтекает. Ну примерно по 100 кб. при каждом открытии. S>Стали бы вы на этом заострять внимание или хрен с ним? S>Как вы вообще относитесь к утечкам — снисходительно или ни байта утечек?
Зависит от. Ситуации разные бывают, стараюсь смотреть на объективные аспекты.
1. Новый код, тем более свой, должен быть без утечек. В современном C++ это настолько просто, что трудно представить какое-то оправдание. No-leak должен быть стилем по-умолчанию, другой код просто не должен проходить review. Тот кто не понимает этот стандартный и простой стиль C++ — банально не проходит моё собеседование.
2. Если это отдельная утилита, которая загружает какие-то данные, обрабатывает их, и выплёвывает результат, и пишется полностью другими отделами, или возможно стажёрами без пристального/грамотного надзора, но поставленную задачу решает корректно и с приемлемым пиковым потреблением ресурсов — ну спасибо им за утилиту и решение проблемы. А внутренний бардак их процесса — он же наружу уши не показывает, и остаётся внутри жёсткого загончика контролируемого ядром.
А какие ещё варианты?
Переписать самому в лишнее несуществующее время?
Заставить их переписать? Это трудно обосновать, ибо объективно задача решена.
3. Если это отдельная утилита (такого же типа как в п.2.) и даже написанная в стандартном стиле без утечек, намеренная и глобальная подмена аллокатора памяти на примитивный (инкрементирующий указатель) но при этом текучий — может в разы ускорить общее время выполнения, и это всего-лишь ценной десятка строчек и повышенным потреблением памяти — вполне себе допустимый инженерный компромисс, ибо есть объективные преимущества, а утечки памяти ограниченны временем жизни процесса.
4. Утечки могут быть необходимы в силу кривого дизайна интерфейса сторонней библиотеки, либо даже её внутренних багов связанных с висящими указателями. В таких случаях намеренная утечка на границе интерфейса, либо насильственное выключение деаллокаций — может быть вполне приемлемым костылём. Но опять таки, желательно эту кривую зависимость вынести в отдельный процесс тем или иным способом, чтобы внутренний бардак не портил всю систему.
5. Очерёдность разрушения глобальных/синглтонов может привести к фиаско, а всякие фениксы и прочие set_longevity могут быть неприменимы по разным причинам — в таких случаях текучий синглтон Майерса может быть вполне приемлемым решением (если достоверно известно что течёт только память).
Спасибо за развернутый ответ. EP>5. Очерёдность разрушения глобальных/синглтонов может привести к фиаско, а всякие фениксы и прочие set_longevity могут быть неприменимы по разным причинам — в таких случаях текучий синглтон Майерса может быть вполне приемлемым решением (если достоверно известно что течёт только память).
Не уверен, что топикстартер знает:
а) что такое синглтон
б) что такое синглтон Майерса
в) что он течет...
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, LaptevVV, Вы писали:
LVV>б) что такое синглтон Майерса LVV>в) что он течет...
Стандартный вариант сам по себе не течёт:
auto& instance()
{
static T x{};
return x;
}
Он гарантирует то что экземпляр будет создан при первом вызове, причём потокобезопасно. Он также будет уничтожен при завершении программы, но порядок этого отследить в большой системе нетривиально. И при завершении может возникнуть ситуация когда один синглтон пытается использовать другой, но тот уже уничтожен. Ещё веселее если там цикл.
Течёт одна из вариаций которая пытается обойти описанную проблему:
Здравствуйте, Shmj, Вы писали:
S>Вот, допустим, приходится вам доработать некую прогу. А там при открытии окна настроек, которое открывается не часто а может вообще никогда — немного подтекает. Ну примерно по 100 кб. при каждом открытии.
S>Стали бы вы на этом заострять внимание или хрен с ним?
Хрен с ним. Хотя, зависит от того, что подразумевается под доработкой. Если в задании сказано, что надо устранить утечки — то придётся заострять внимание. А если утечки раньше никого не парили, то с чего бы мне беспокоится
S>Как вы вообще относитесь к утечкам — снисходительно или ни байта утечек?
В том, что пишу я сейчас — ни байта утечек. Благо C++ сам всё разруливает.
А так — как-то дописывал чужую консольную утилитку на сишечке, которая парсила вход и выплевывала выход — я там не стал разбираться, кто на ком стоит и кто чем владеет, и просто делал malloc без всяких free. На любых разумных объемах входных данных тулза отрабатывала нормально, и меня это вполне устроило
Здравствуйте, пффф, Вы писали:
EP>> static auto& x = *new T{}; П>Я бы не сказал, что это утечка
Ну если там только память — то это рояли не играет.
Но внутри T может быть любой ресурс, или какой финализатор. Пример с потолка — например этот T формирует xml отчёт и в деструкторе закрывает тэги.
