зачем делать метод, который просто возвращает 0?

Автоматический кодогенератор во мне говорит вариант 2...

да и вообще, разве ещё кто-то программирует на си-крест-крест?

зачем делать метод, который просто возвращает 0?

Как вариант - имплементация некоего абстрактного интерфейса в вакууме.

Во 2-ом коду понятнее. :)

s/коду/коде

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

Писал «Только моно, только удобства!», а оба раза получилось «толсто».. :)

Да. А почему бы и нет?

debtags search implemented-in::c++ выдал весьма солидный списочек, так, что не я один: http://pastebin.com/7zSvenfY

Раз нужны такие костыли, значит, фиговый это интерфейс.

За тем же зачем называть класс «A», а функцию - func1()

Всё что можно инлайн - первый вариант. Но на плюсах я пишу один школокод.

А если inline?

Почему это костыль? Очень часто в интерфейсах бывают функции вроде name() или id().

Потому что абстрактные функции должны быть абстрактными. И.О. К.О.

А если инлайн, то вынести ее в отдельный .cpp не выйдет.

Когда пишу для себя - 1 вариант ибо сжимает исходники и при поломке починить - 5 минут.

Для работы - 2 всегда. Инлайны можно и явно указать.

Есть шанс, что метод в будущем разрастется, поэтому лучше сразу все оформлять в cpp
Плюс не будет проблем, когда глазами по файлу ищешь метод, а его там нет, т.к. решили его в h оставить.

А inline-квалификатор разве не прокатит? Я сам точно не помню, давно на плюсах не писал.

А inline-квалификатор разве не прокатит?

нет

Я про то, что в реализации чисто абстрактной функции такое встречается. И.О. К.О.

Я немного о другом подумал. Но name() и id() - обычно тоже костыли, следствие неподдержки языком рефлексии (да и цели, ради которых необходимы константные в пределах типа name() и id(), неясны: для проверки, нужный ли это тип, есть dynamic_cast, но чем меньше его, тем лучше архитектура).

C++ конечно ужасен, но за излишнее использование рефлексии нужно руки отрывать.

Не прокатит. inline-функция должна быть реализована в той же единице трансляции, в которой и используется, иначе нет физической возможности ее заинлайнить.

иначе нет физической возможности ее заинлайнить.

Логично. Об этом я мог бы (и должен был бы) и сам догадаться. :)

Чтобы name(), id() не смущали, вот ещё некоторые варианты использования: description, supported_formats, etc.

А inline-квалификатор разве не прокатит? Я сам точно не помню, давно на плюсах не писал.

Если метод реализован внутри описания класса, то он по умолчанию считается inline. Другое дело, что во многих случаях (рекурсия, виртуальный вызов) заинлайнить не удастся.

А ведь вполне возможно, что мне вскоре придётся вспоминать все эти премудрости С++ (наклёвывается некоторый проектик). Поэтому - по теме - я выбираю второй вариант, как более «перспективный». :)

А что плохого в применении рефлексии там, где она уместна? (т.е., вместо name() и id())

Мой список найденных недостатков C++ (пополняется благодаря ЛОРу):

1) нет интроспекции и рефлексии

2) в некоторых случаях - многословный

3) statement-oriented, а не expression-oriented

4) тащит совместимость с C, добавляя этим еще одну возможность написать говнокод

Этого, ИМХО, недостаточно, чтобы считать его ужасным. Еще будут?

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

Директива inline тоже игнорируется, если метод невозможно заинлайнить.

Если метод реализован внутри описания класса, то он по умолчанию считается inline.

Не, это мои дряхлые мозги пока ещё помнят. Я имел в виду, что если вынести метод из описания класса (в .h) в .cpp-файл и добавить к нему квалификатор inline, то станет ли он инлайновым? Но мне уже объяснили, что такое не прокатит по вполне резонным причинам.

реализации чисто абстрактной функции такое встречается

реализации

чисто абстрактной функции

struct LOL { virtual int WUT() = 0 { return 0; } };
int main() { return LOL().WUT; }

Сегодня я заменяю Капитана, обращайтесь

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

2) в некоторых случаях - многословный

Это почти во всех случаях, когда код пишется по стилю C++. Наследуешься от класса с 5 конструкторами? Пиши в своём классе все эти 5 конструкторов снова. Пишешь интерфейс? Заголовок копипастишь в 2 хедера, и ещё 1 в реализации.

5) Очень контекстно-зависимый. Когда на него навешивают перегрузку операторов, преобразования типов и перегрузку функций (подсоленный разнообразием const и не const), то найти operator или метод, который вызывается в данной конкретной строчке - нетривиальная задача (мало того, из-за краткости ещё и не сразу догадаетесь, что тут что-то вызывается). Аналогично - изменив operator или типы аргументов метода можно поломать последующий код, совершенно не заметив этого.

6) Дефолтные оператор присваивания и конструктор копирования почти всегда не применимы, и необходимо их описывать самому (или дебагать потом их случайный вызов).

7) Чтобы код был бинарно переносим, нужно использовать pimpl для private переменных, что добавляет в него ещё кучу мусора, не относящегося к решению задачи.

5) что можно перегружать операторы - это хорошо. в контекстной зависимости проблемы не вижу. при желании поломать все можно

6) покажи, где не так

7) вот тут да, этот пункт можно дописать к моему списку. хотя иногда от дублирования кода можно избавиться путем наследования.

Обычно инлайню и пишу, как в варианте два, но реализация остается в заголовочном файле. Загрязнять интерфейс класса не люблю.

2.

Не прокатит. inline-функция должна быть реализована в той же единице трансляции, в которой и используется, иначе нет физической возможности ее заинлайнить.

второй вариант можно и заголовочном файле сделать

Я знаю.

1й вариант только если сильно хочется инлайн, либо если хочешь обойтись без cpp.

Однозначно 1. Вот когда метод разрастется, вот тогда и можно его в .cpp переносить, а раньше то зачем???

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

Со вторым подходом это не порождало бы проблем.

Не хватает мне воображения... если либа изменилась, то ее по любому пересобирать.

[code=c] class A { int func1(); };

int A::func1() { return -1; } [/code]

Либу - пересобирать. Приложение, ее использующее - нет, если либа сделана правильно.

3.

class A {
  int i;
  inline int f() { return i; }
}

Народную мудрость про «подстилание соломки в месте вероятного падения» ещё никто не отменял. :)

Для меня однозначно 2-й способ - лучше. «Безграбельнее», так сказать.

Приложение, ее использующее - нет, если либа сделана правильно.

Согласен. Но все же случай достаточно гипотетический ИМНО.

Народную мудрость про «подстилание соломки в месте вероятного падения» ещё никто не отменял. :)

Работать надо а не за соломой бегать;-) Вот нафига плодить лишние строчки кода + размазывать тривиальные вещи по двум файлам вместо одного???