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

V>А потом мы тут все возмущаемся падучести многих программ.

Так спросите авторов падучих программ, почему они падают.

12/23/2013 3:17 PM, alexku пишет:

> Так спросите авторов падучих программ, почему они падают.
Ты уже ответил.

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

TB>>Сколько времени ты потратил на отладку операций с памятью, вместо того, чтобы использовать смартпоинтеры?
A>Практически нисколько.

Исключения используются?

A>В нормально спроектированном коде все точки выделения и освобождения памяти заранее известны.

В большинстве случаев это действительно так — именно shared семантика требуется редко. shared_ptr'ы частенько абузятся не по делу.
Но чем не угодили RAII, RVRef/Move, scoped_ptr, unique_ptr?

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

V>Ты уже ответил.

Ну-ка, ну-ка, расскажи мне, где и когда ты пользовал что-либо написанное мной?

И не забудь сменить прокладку.

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

A>Практически нисколько. В нормально спроектированном коде все точки выделения и освобождения памяти заранее известны.

Они-то может и известны, но зачем лишний раз про них помнить, усложняя код?

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

EP>Но чем не угодили RAII, RVRef/Move, scoped_ptr, unique_ptr?

Да ничем. Это был ответ на быдлокодеров. Следование догмам, это ведь так неумно, верно?

EP>Исключения используются?

Только те, которые генерируются сторонними библиотеками, в основном stl. Да и то они преобразуются в код ошибки.
Опять же, я ничего не имею против исключений. Просто в данном случае так оказалось удобнее.

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

A>Следование догмам, это ведь так неумно, верно?

Это конечно верно, но иногда проще дать людям догмы, чем прокачивать critical thinking.
Например — многие боятся как огня goto, глобальных объектов, хотя у них есть вполне нормальные use-case'ы. Но если каждый их будет использовать не по делу — то будет хаос. Опиум народа помогает защищаться от этого хаоса.

EP>>Исключения используются?
A>Только те, которые генерируются сторонними библиотеками, в основном stl. Да и то они преобразуются в код ошибки.
A>Опять же, я ничего не имею против исключений. Просто в данном случае так оказалось удобнее.

Я о том, что в коде с ручным управлением ресурсами и летающими исключениями, очень легко допустить утечку. В тестах редко проверяется exception safety, поэтому утечки такого класса трудно предупреждать без использования RAII.
Есть много кода с ручным управлением памяти который "типа не течёт", но это только до первого исключения.

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

A>Следование догмам, это ведь так неумно, верно?

Усложнение жизни на ровном месте, это ведь так неумно, верно?

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

EP>Я о том, что в коде с ручным управлением ресурсами и летающими исключениями, очень легко допустить утечку. В тестах редко проверяется exception safety, поэтому утечки такого класса трудно предупреждать без использования RAII.
EP>Есть много кода с ручным управлением памяти который "типа не течёт", но это только до первого исключения.

Проблем с летающими исключениями нет, потому что они не летают. Они обрабатываются ровно там, где возникают, и никуда дальше не идут. И конструкторы не генерируют исключения. В них просто нет кода, который мог бы спровоцировать исключение. Я не могу себе позволить такую роскошь. Объект может быть не создан только по одной причине — нехватка памяти.

Сейчас, кстати, заглянул в код. В нём остался ровно один блок try-catch, остальные давно выпилены. Да и этот после внимательного рассмотрения ждёт та же судьба. Спасибо, что дали повод лишний раз пересмотреть код. Простой if() не доведёт до возможности возникновения исключения. Это будет и нагляднее, и надёжнее. Так что с exception safety проблем нет.

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

TB>Они-то может и известны, но зачем лишний раз про них помнить, усложняя код?

Почему усложнять? Нормальная декомпозиция позволяет определить жизненный цикл объектов и необходимость того или иного подхода. В данном конкретном случае, хоть объём кода и большой, смартпойнтеры оказались просто не нужны. Вот и всё. Но если я при этом быдлокодер, ну и славабогу. Мне от этого ни жарко, ни холодно. Мой быдлокод оплачивается хорошо и работает надёжно, чтобы не париться по этому поводу.

12/23/2013 7:31 PM, TarasB пишет:

> Усложнение жизни на ровном месте, это ведь так неумно, верно?
Зато можно бесконечно долго пилить одну программу.

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

A>Почему усложнять?

потому что вместо

unique_ptr<T> smth = new T;

тебе придётся в начале писать

T* smth = new T;

а в конце

delete T; // ой не забыть бы !!!!

больше букв, больше зависимостей внутри кода, больше шансов ошибиться.

Или вместо

do_smth(get_smth())

тебе придётся писать

T* smth = new T;
get_smth(T);
do_tmth(T);
delete T;

и ещё куча случаев.

Ясно, боишься "высокого порога вхождения" — тогда уж java net и прочее (сборщики мусора)

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

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

Ш>>>Будь добр тогда объяснить, что ты понимаешь под утечкой памяти. В моём понимании, утечка памяти -- это продолжение времени жизни объекта сверх необходимого из-за ошибки в программе.
K>>Под утечкой памяти, я имел ввиду ситуацию при которой указатель на объект не существует, а объект на который он указывал не удалили. Фактически, такую память не найдёшь и не осободишь. В общем случае, любая ссылка на любой ресурс подвисшая в программе и не обработанная должным образом это по сути утечка ресурса.

К>А в чём идея этого разделения?
Считай, что фетиши не совсем продвинутых преподов покусали меня и эти раны до сих пор открываются .

12/24/2013 10:04 AM, TarasB пишет:

> тебе придётся в начале писать
> T* smth =new T;
А в промежутке вылетит неожиданное исключение, или кто-то не учтет и
пустит логику программы по другое ветке.
> а в конце
> delete T;// ой не забыть бы !!!!

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

V>12/24/2013 10:04 AM, TarasB пишет:

>> тебе придётся в начале писать
>> T* smth =new T;
V>А в промежутке вылетит неожиданное исключение, или кто-то не учтет и
V>пустит логику программы по другое ветке.
>> а в конце
>> delete T;// ой не забыть бы !!!!

А, ну да. Тогда так:

T* smth =new  T; // внутри следующего куска кода не делать никаких return и исключений!!!!!!
...
delete  T;// ой не забыть бы !!!!

12/24/2013 1:45 PM, TarasB пишет:

> T* smth =new T;// внутри следующего куска кода не делать никаких return и исключений!!!!!!
А если кто допустит, сразу к стенке?
А если до кода, где new 3 версты и до delete не меньше?
STL, у вас, понятно под запретом, не говоря уже от Boost и иже с ним.

12/24/2013 2:10 PM, Vzhyk пишет:

> STL, у вас, понятно под запретом, не говоря уже от Boost и иже с ним.
Тьфу, блин. Ты тут не причем, это у того, кто подобное отстаивал с new.

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

V>А если кто допустит, сразу к стенке?

А если кто допустит, то спихиваем вину на него. Это же так приколько, когда начальник ругает кого-то, но не тебя!

12/24/2013 3:15 PM, TarasB пишет:
> А если кто допустит, то спихиваем вину на него. Это же так приколько,
> когда начальник ругает кого-то, но не тебя!
А, ну да, самый цимес-то я и забыл.