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

S>Вот, допустим, приходится вам доработать некую прогу. А там при открытии окна настроек, которое открывается не часто а может вообще никогда — немного подтекает. Ну примерно по 100 кб. при каждом открытии.
S>Стали бы вы на этом заострять внимание или хрен с ним?
S>Как вы вообще относитесь к утечкам — снисходительно или ни байта утечек?

Зависит от. Ситуации разные бывают, стараюсь смотреть на объективные аспекты.

1. Новый код, тем более свой, должен быть без утечек. В современном C++ это настолько просто, что трудно представить какое-то оправдание. No-leak должен быть стилем по-умолчанию, другой код просто не должен проходить review. Тот кто не понимает этот стандартный и простой стиль C++ — банально не проходит моё собеседование.

2. Если это отдельная утилита, которая загружает какие-то данные, обрабатывает их, и выплёвывает результат, и пишется полностью другими отделами, или возможно стажёрами без пристального/грамотного надзора, но поставленную задачу решает корректно и с приемлемым пиковым потреблением ресурсов — ну спасибо им за утилиту и решение проблемы. А внутренний бардак их процесса — он же наружу уши не показывает, и остаётся внутри жёсткого загончика контролируемого ядром.
А какие ещё варианты?
Переписать самому в лишнее несуществующее время?
Заставить их переписать? Это трудно обосновать, ибо объективно задача решена.

3. Если это отдельная утилита (такого же типа как в п.2.) и даже написанная в стандартном стиле без утечек, намеренная и глобальная подмена аллокатора памяти на примитивный (инкрементирующий указатель) но при этом текущий — может в разы ускорить общее время выполнения, и это всего-лишь ценной десятка строчек и повышенным потреблением памяти — вполне себе допустимый инженерный компромисс, ибо есть объективные преимущества, а утечки памяти ограниченны временем жизни процесса.

4. Утечки могут быть необходимы в силу кривого дизайна интерфейса сторонней библиотеки, либо даже её внутренних багов связанных с висящими указателями. В таких случаях намеренная утечка на границе интерфейса, либо насильственное выключение деаллокаций — может быть вполне приемлемым костылём. Но опять таки, желательно эту кривую зависимость вынести в отдельный процесс тем или иным способом, чтобы внутренний бардак не портил всю систему.

5. Очерёдность разрушения глобальных/синглтонов может привести к фиаско, а всякие фениксы и прочие set_longevity могут быть неприменимы по разным причинам — в таких случаях текущий синглтон Майерса может быть вполне приемлемым решением (если достоверно известно что течёт только память).

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

S>Вот, допустим, приходится вам доработать некую прогу. А там при открытии окна настроек, которое открывается не часто а может вообще никогда — немного подтекает. Ну примерно по 100 кб. при каждом открытии.
S>Стали бы вы на этом заострять внимание или хрен с ним?
S>Как вы вообще относитесь к утечкам — снисходительно или ни байта утечек?

Зависит от. Ситуации разные бывают, стараюсь смотреть на объективные аспекты.

1. Новый код, тем более свой, должен быть без утечек. В современном C++ это настолько просто, что трудно представить какое-то оправдание. No-leak должен быть стилем по-умолчанию, другой код просто не должен проходить review. Тот кто не понимает этот стандартный и простой стиль C++ — банально не проходит моё собеседование.

2. Если это отдельная утилита, которая загружает какие-то данные, обрабатывает их, и выплёвывает результат, и пишется полностью другими отделами, или возможно стажёрами без пристального/грамотного надзора, но поставленную задачу решает корректно и с приемлемым пиковым потреблением ресурсов — ну спасибо им за утилиту и решение проблемы. А внутренний бардак их процесса — он же наружу уши не показывает, и остаётся внутри жёсткого загончика контролируемого ядром.
А какие ещё варианты?
Переписать самому в лишнее несуществующее время?
Заставить их переписать? Это трудно обосновать, ибо объективно задача решена.

3. Если это отдельная утилита (такого же типа как в п.2.) и даже написанная в стандартном стиле без утечек, намеренная и глобальная подмена аллокатора памяти на примитивный (инкрементирующий указатель) но при этом текучий — может в разы ускорить общее время выполнения, и это всего-лишь ценной десятка строчек и повышенным потреблением памяти — вполне себе допустимый инженерный компромисс, ибо есть объективные преимущества, а утечки памяти ограниченны временем жизни процесса.

4. Утечки могут быть необходимы в силу кривого дизайна интерфейса сторонней библиотеки, либо даже её внутренних багов связанных с висящими указателями. В таких случаях намеренная утечка на границе интерфейса, либо насильственное выключение деаллокаций — может быть вполне приемлемым костылём. Но опять таки, желательно эту кривую зависимость вынести в отдельный процесс тем или иным способом, чтобы внутренний бардак не портил всю систему.

5. Очерёдность разрушения глобальных/синглтонов может привести к фиаско, а всякие фениксы и прочие set_longevity могут быть неприменимы по разным причинам — в таких случаях текучий синглтон Майерса может быть вполне приемлемым решением (если достоверно известно что течёт только память).