Если они нужны, но их нет в языке программирования, то остаётся только делать функции типа
Что-то в этом роде? Я примерно так делаю, а как бы сделали вы? Хотя может быть return null тоже неплохой вариант...

zloy denЛучше экзепшн имхо. Так будет точно понятно что этой функциональности в классе нет.
Ну и замечательно. Спасибо. Просто хотел убедиться, что не я один так считаю :)

an0nymXDiaBLo
"Метод еще не осознан"? :)

Not implemented yet... Уж лучше б по-русски писали, чем такой кривой английский потом в коде видеть.
Тьфу, да, точно. Ошибся, с кем не бывает. Проверил, Нетбинс вообще "Not supported yet." пишет.

maytonXDiaBLoЕсли они нужны, но их нет в языке программирования, то остаётся только делать функции типа
Что-то в этом роде? Я примерно так делаю, а как бы сделали вы? Хотя может быть return null тоже неплохой вариант...
Возможно - это следствие неудачного дизайна базового класса или интерфейса. У меня тоже часто были муки творчества, когда долго смотрел на интерфейс и думал... а нахера собсно там там много методов?

А подобные throw-s вставляет Netbeans или другая IDE.

Я-бы туда запихнул assert(..)
Да не, просто баловался с шаблонами проектирования, читал в книге GoF, но писал не на C++, а на ActionScript, но тут пример на яве привёл. Чтобы не пугать людей. И пытался воплощать в код, именно как в книге, без своего творчества, которое на практике вообще-то вполне допустимо и желательно. Но для начала хотелось сделать точно по библии. И наткнулся на отсутствие абстрактных классов. Вот и извращаюсь.

maytonА может быть так надо сделать? Всё таки XML... едрён-батон.

У меня там было
Это в программе откуда кусок скопировал. Просто переиначил, чтобы под вопрос подходило

an0nymXDiaBLoно писал не на C++, а на ActionScript, но тут пример на яве привёл
Прелестно.
Да один фиг, ни там, ни там абстрактных классов нет. Чегож народ пугать?

ПетросъянАльмалексияПетросъянну и вылетит потом в проге
Не должны быть перменные типа абстрактного класса.
Если их не будет, то и исключений соотвественно.
Если бы у меня была такая ситуация, сделал бы также как автор.
зачем тогда исключение если его все равно не будет?
Чтобы если случайно где-то вдруг попытаешься получить экземпляр абстрактного класса, получить в конце концов эксепшен. Хотя бы когда-нибудь в рантайме.

MozokXDiaBLo
Да один фиг, ни там, ни там абстрактных классов нет. Чегож народ пугать?
На Яве нет абстрактніх классов? Это откуда такая деза?
Расскажи нам про них.

Хмм, я ошибался
Ну да ладно, вопрос обсудили, уже не буду приводить примеры на ЭкшнСкрипте. Я даже и не знал про абстрактные классы в Яве, то-ли забыл, то-ли проморгал.

maytonXDiaBLoЯ даже и не знал про абстрактные классы в Яве, то-ли забыл, то-ли проморгал.
Ай-ай-ай
Совсем уже с ума свели Я пытаясь работать с тремя языками параллельно, совсем в них запутался Ща сижу, на С++ пишу, дома на ЭкшнСкрипте, а на той неделе на работе с Явой ковырялся.

Петросъянвезде понемногу, нигде хорошо
Везде хорошо, но не отлично. Так точнее будет.

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

Модератор: Товарищи, спокойнее :)

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

MAYAKOV_SVXDiaBLo
Да, хотелось бы в юнит-тесты завернуть, да что-то не пойму как их к С++ Билдеру прикрутить. Вручную тестирую
Тестирование - вообще мое самое слабое место.
Книгу все собираюсь почитать по этой теме.
Но мой опыт мне показал, что к тестированию нужно очень серьезно относиться.
Хорошо, если пользователь - добрая и терпеливая тётя, или ошибка в программе не так серьезно может отразится. А если нет?...
В этом плане, я побаиваюсь делать рефакторинг.
Если делаю, то только на разрабатываемом проекте, но не на уже работающем.
Я делаю рефакторинг на уже работающем проекте. Ибо приходится вносить изменения, а программа настолько неповоротлива, что нужно по всему телу программы вносить изменения, ради какой-нибудь мелочи. Поэтому я стараюсь локализовать изменения, переименовать объекты из ComboBox1 во что-нибудь внятное, типа cmbClientGroups и всякое в этом роде. Вчера как раз занимался переименованием всех этих комбо, чек, и каких бы то ни было боксов. Не понимаю, как тот программист вообще с этим управлялся...