Разве _стиль_программирования_ должен диктоваться исключительно соображениями оптимизации работы программы по памяти или скорости?... Мне кажется что "удобство пользования" кодом тоже важно, особенно когда есть много кода и много людей с ним работающих.
Удобство пользования кодом всегда на первых местах, именно поэтому не стоит использовать char Text = new char[TextLength]. В таком случае нельзя будет просто написать return - нужно задумываться о том, кто освободит память.
В таком случае нельзя будет просто написать return - нужно задумываться о том, кто освободит память. Можно 100 раз задуматься о том, кто должен освободить память, и писать delete перед каждым return'ом. И всё равно получить утечку. Потому что можно банально не добраться до этого return'а, если выпадет иключение.
Если вы используете вызовы чужих функций, то надо по умолчанию предполагать, что они бросают исключение. Если между new и delete нет ничего, что может сгенерировать исключение, то надо по умолчанию предполагать, что кто-то в будущем туда его добавит.
В общем, умные указатели в вашем Coding Standard'е — безусловно полезная штука. Но не потому что „удобно“ или „не нужно задумываться“. А потому что „более безопасно с точки зрения исключений“. Имхо, именно так должен звучать rationale.
5 комментариев:
А почему уж тогда не std::string? ;-)
Или на крайний случай просто char[TextLength]...
1. sizeof(string) больше sizeof(scoped_array)
2. размер стека меньше размера динамической памяти
Разве _стиль_программирования_ должен диктоваться исключительно соображениями оптимизации работы программы по памяти или скорости?... Мне кажется что "удобство пользования" кодом тоже важно, особенно когда есть много кода и много людей с ним работающих.
Удобство пользования кодом всегда на первых местах, именно поэтому не стоит использовать char Text = new char[TextLength]. В таком случае нельзя будет просто написать return - нужно задумываться о том, кто освободит память.
В таком случае нельзя будет просто написать return - нужно задумываться о том, кто освободит память.
Можно 100 раз задуматься о том, кто должен освободить память, и писать delete перед каждым return'ом. И всё равно получить утечку. Потому что можно банально не добраться до этого return'а, если выпадет иключение.
Если вы используете вызовы чужих функций, то надо по умолчанию предполагать, что они бросают исключение. Если между new и delete нет ничего, что может сгенерировать исключение, то надо по умолчанию предполагать, что кто-то в будущем туда его добавит.
В общем, умные указатели в вашем Coding Standard'е — безусловно полезная штука. Но не потому что „удобно“ или „не нужно задумываться“. А потому что „более безопасно с точки зрения исключений“. Имхо, именно так должен звучать rationale.
Отправить комментарий