pizmonПо теме - assert разве не для этого? В релизе промолчит, в отладке обругается. Если нет поддржки assert со стороны языка, то всегда можно какой-нибудь заменитель изобразить, IMHO.
А когда по вашему assert отработает?

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

pizmonegorychисключение можно проигнорировать, ассерт - никогда, или это не ассерт

Ну, assert - в конечном итоге тоже исключение.
Я для себя решил так: если пользователь может что-то поделать с проблемой, то это должно быть оформлено исключением (File not found, Host unreachable, Disk full и так далее), теоретически доходящим до пользователя, а если пользователь тут ни ухом, ни рылом помочь не может, то лучше бы тут был отключаемый assert (вот вызов "запрещенного" метода - как раз тот случай).
Но это моё мнение, я на нем не настаиваю :)
Ога, а юзер потом будет говорить:"у меня не работает, разберитесь", и никакой более информации. Это ещё хорошо, если получится воссоздать ошибку у себя на машине, повторив его действия. Но иногда ошибка может быть повторимой только на его машине. Как быть?

pizmonXDiaBLoНо иногда ошибка может быть повторимой только на его машине. Как быть?

Ставить ему test build, думать об этом... как-то так. Трудно и не везде применимо, согласен.
Именно, не везде. Нужно чтобы релиз показывал все важные ошибки, а тётя, у которой ошибка случилась, могла бы зачитать сообщение.

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

В порядке трёпа:
Тестирование с помощью тёти - не наш метод. Вообще-то, тёте надо видеть сообщения в форме простых команд, типа "Выкинь отсмотренное кино с винчестера", "Воткни патчкорд в дырку", "Больше так не делай". Все остальные сообщения для тёти обычно сливаются в одно могучее "Shit happens", и при анализе опираться на устные показания тёти не стоит по-любому, imho. Сбрось в файлик настоящий Exception, стек, дату, время, разные важные параметры (в том числе, например, трек пройденных и "заглоченных" assertов, если будете свою их реализацию делать), и нехай тётя файлик этот по мылу пришлёт. Не грузите тётю сообщениями типа "Abstract Error" или, например, незабываемое "Произошел разрушительный сбой по адресу XXXXXXXX". Тёте что этот адрес, что разрушительная сила сбоя, что ваши абстракции - до одного и того же фонаря.
Тёти мне звонят и пишут, описывают ситуацию. Но я всё подумываю сделать сервачок, на который будет регистрироваться весь порядок действий пользователей. Чтобы с пары нажатий кнопок, видеть всю ситуацию. Пока некогда такое делать, но сплю и вижу такое.

MAYAKOV_SV,
А есть ситуации, где без абстрактных классов возникнет либо дублирование кода, либо базовый класс, который допускает инстанцирование, при том, что он сам по себе, использоваться не должен. Как быть?

MAYAKOV_SV,
Хочу кое-что со стратегиями сделать. Ща там лапша на тыщу строк, которую я уже немного упорядочил. Любопытно будет увидеть что получится.

MAYAKOV_SV,
Я подозреваю что вы всё же имеете в виду что-то типа того, чтобы наследовать все классы от одного интерфейса, а то, что было бы в абстрактном классе, реализовывать в отдельном классе, и использовать его через агрегирование. В таком случае в вашем коде не хватает общего предка. Причём в С++ сие смысла не имеет, а в языках без абстрактных классов, но с интерфейсами, имеет. Вот это уже хороший вариант, спасибо.

MAYAKOV_SV,
Да ёмоё, если нужно чтобы всё же было наследование, но при этом не подходит конкретный класс в качестве родителя, и нужно не дублировать код в наследниках, то как вы предлагаете обойтись без абстрактного класса, как не совмещением наследования интерфейса и агрегирования?

MAYAKOV_SVXDiaBLoMAYAKOV_SV,
Да ёмоё, если нужно чтобы всё же было наследование, но при этом не подходит конкретный класс в качестве родителя, и нужно не дублировать код в наследниках, то как вы предлагаете обойтись без абстрактного класса, как не совмещением наследования интерфейса и агрегирования?
Если вам агрегирование поможет, я только рад, я не против.
Главное не забывайте тестировать, если рефакторите существующий код.
Да, хотелось бы в юнит-тесты завернуть, да что-то не пойму как их к С++ Билдеру прикрутить. Вручную тестирую