Приемы программирования на C++

Прочитай Мейерса «Эффективное использование C++».

Прочитай Мейерса «Эффективное использование C++».

++

Александреску А., Саттер Г. Стандарты программирования на С++

Саттер Г. Решение сложных задач на С++

Саттер Г. Новые сложные задачи на С++

мелочей таких как проверка на самого себя в конструкторе копирования?

что? может все же в операторе присваивания? и да, это не мелочь.

кроме мелочей таких как проверка на самого себя в конструкторе копирования

Никакой это не правильный стиль программирования. Проверка самого себя оптимизацией быть вообще не может, ибо код всегда можно отпрофилировать и найти это пресловутое присвоение самому себе, а добавлять лишнюю проверку к нормальному коду станет добавлять только норкоман. Норкоман, начитавшийся Александреску.

Вот в книгах Александреску и всяких «профессиональных C++», «приёмах владения C++» этот стиль и излагается. В рамках общего развития скажу, что стили Qt, LLVM или гугла отличаются от этого книжного стиля и несколько более практичны, на мой вкус.

то стили Qt, LLVM или гугла отличаются от этого книжного стиля и несколько более практичны, на мой вкус.

Это там где 11й сигнал в потоке перехватывают, чтобы сделать что-то осмысленное? Вот уж точно наркомания. Я бы таких «погромистов» отлучал бы от компа.

У меня даже Visual Studio, бывало, крашилась. А ведь microsoft на все продукты кучу тестеров кидает. Зато в LLVM креш в реальности не страшен. В воображении фанатов 32 бит - да, страшен.

Я вообще за плюрализм. Стиль Александреску и прочих очень популярен, так ради бога, пусть живут себе; недостающие вещи восполнят остальные взгляды и мнения. Но вот за такое

Я бы таких «погромистов» отлучал бы от компа.

Надо намордник вешать. К счасть, вы далеко не один такой - нетерпимость к чужим взглядам вообще характерна для многих, кто-то бы вовсе убивать осиновым колом предпочёл.

У тебя память процесса испорчена, всё, сделать ничего нельзя, можно только записать (причем write, а не printf!) в stdout с красивым сообщением и упасть. Кто считает иначе того к программированию нельзя подпускать на пушечный выстрел и спор здесь не уместен.

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

Да, непрофессионализм я не терплю.

Сразу видно писателя утилок, никогда в поле не развертывавшего системы посложнее. Можно например попробовать несохраненные данные скинуть в лог, если они еще не там, и самозапуститься в режиме восстановления и генерации репорта. Или автоматизировать багрепорты не кошерно?

Можно например попробовать несохраненные данные скинуть в лог

Во-первых, есть большая вероятность, что «несохраненные» данные уже попортились. Во-вторых, для этого придумали транзакции. В-третьих, в лог кидать опасно, так как есть большая вероятность задедлочиться в каком-нибудь gettimeofday.

самозапуститься в режиме восстановления и генерации репорта.

Для этого есть watchdog в виде отдельного процесса.

Или автоматизировать багрепорты не кошерно?

Кошерно, но делать это надо не через жопу как ты предлагаешь.

Мейерс, конечно. И ещё мне советовали Дюхарста, но я пока так и не удосужился.

проверка на самого себя в конструкторе копирования

А разве такое возможно в принципе? о_О

http://www.ozon.ru/context/detail/id/2631001/

ко всем вышеперечисленным.

проверка на самого себя в конструкторе копирования

А разве такое возможно в принципе? о_О

ну такой синтаксис во всяком случае позволяет это сделать

class A {
public:
A(const &other) {}
};
...
A a = a;

другое дело, что смысла в этой проверке нет, и автор абсолютно точно имел в виду проверку на самого себя в операторе присваивания.