Функция определена в классе, а тело функции находится вне класса.
Почему так делают?

Или жетело функции располагают в:

Код

class name { public: void funktion() {тело}; }

Разве так удобно? Имхо гораздо удобнее в public, pivate, protected описать только по-определять функции, а снизу в этом же классе уже изложить сами функции. Такое возможно?

А то я видел только еще такой вариант:

Код

class name { public: void funktion(); } name::function () { }

PS. За синтаксис не ручаюсь

class name {
public:
void funktion() {тело};

}

это делается если тело функции -- пара строк ( например:
...
public:
...
int getId() {return id; };
)
>>Разве так удобно?
мне -- удобно
>>Имхо гораздо удобнее в public, pivate, protected описать только по-определять функции, а снизу в этом же классе уже изложить сами функции.
это из Java?

>>А то я видел только еще такой вариант:
class name {
public:
void funktion();
}
name::function () {
}

так можно ( только реализацию в .cpp вынести нужно )

Цитата(_hunter @ 14.12.2004, 12:12)

так можно ( только реализацию в .cpp вынести нужно )

А поподробнее можно? Разве классы не в .cpp создавать надо?

Цитата(_hunter @ 14.12.2004, 12:12)

class name { public: void funktion() {тело}; } это делается если тело функции -- пара строк ( например: ... public: ... int getId() {return id; }; ) >>Разве так удобно? мне -- удобно

А если не пару строк, то как поступать?

Цитата(_hunter @ 14.12.2004, 12:12)

это из Java?

Хм.. из логики

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

Admin

Цитата

Разве так удобно? Имхо гораздо удобнее в public, pivate, protected описать только по-определять функции, а снизу в этом же классе уже изложить сами функции. Такое возможно?

Это уже дело вкуса и стиля программиования

Если функция объявлена и определена в *.Н - это inline функция. Вот, такое будет говорить компилятору, что это инлайн функция:

Код

class name { public: void funktion() {тело}; };

Но в тоже время, это не факт, что она 100% будет инлайн. Это будет решать компилятор Т.е. если в теле функции будет ветвления, типа if() {...} else{...}, то компилятор не будет приминять идентифиукатор inline. Т.е. это на усмотрение компилятора. Но если мы хотим все же сделать 100% инлайн, то нужно добавить, например в MSVC, идентификатор __forceinline.

З.Ы.: Не знаю, что-то написал. Если не понятно, извиняйте

Добавлено @ 14:26

Цитата

А поподробнее можно? Разве классы не в .cpp создавать надо?

Можно

Функции лучше создавать в файлах с расширением .h, а не .cpp ?

Цитата

А поподробнее можно? Разве классы не в .cpp создавать надо?

классы _создаются_ в двух местах:

в .h файле идет описание:

Код

class name { public:    void funktion(); };

а в .cpp идет реализация:

Код

void name::funktion() { ... }

про джаву упомянул так как там используют однофайловую структуру ( очень похожую на описанную )

Это сообщение отредактировал(а) _hunter - 14.12.2004, 14:33

Цитата

Но если мы хотим все же сделать 100% инлайн, то нужно добавить, например в MSVC, идентификатор __forceinline.

Не факт, что 100%
Вот это компилятор встроить не сможет

Код

__forceinline void func(void) {    // ... } int main(void) {    void (*p)(void) = func;     func(); // функция встроена не будет! }

Admin

Цитата

Функции лучше создавать в файлах с расширением .h, а не .cpp ?

Нннн-ет. Все же лучше в *.cpp
ИМХО: если класс маленький, т.е. с парой-другой коротеньких функция, то лучше все запихнуть в *.h

Цитата(_hunter @ 14.12.2004, 12:31)

про джаву упомянул так как там используют однофайловую структуру ( очень похожую на описанную )

ага..., вот как интересно... Оказывается все-таки стандартом в С++ является разделение описания и реализации класса.
Теперь все сильно проясняется.
Добавлено @ 14:35

Цитата(bel_nikita @ 14.12.2004, 12:34)

ИМХО: если класс маленький, т.е. с парой-другой коротеньких функция, то лучше все запихнуть в *.h

И при этом реализацию функий делать прямо в секции public, private или protected?

соответственно _маленькие_ функции ( выполняющие _понятные_ действия ) лучше писать в опимании класса, остальные -- выносить в реализацию

но, как уже упоминали, это все дело стиля

А по другому не дано? Т.е. делать реализацию внутри класса, но не в описании?

не в секции, а именно в месте определения:

Код

class name { public:    void funktion() { что-то_делаем; }; };

Если описание класса делать в заголовочном файле h, а реализацию - в cpp, это даёт возможность без проблем использовать наш класс в других наших программах, где нужно будет только включить наш заголовочный файл.
А вот когда создали Object Pascal, то там это реализовали путем введения областей interface и implementation. Видимо, если модуль с описанием класса используется в других модулях, то компилятор ориентируется лишь в interface области кода.

Представь, тебе надо написать интерфейс. Короче говоря класс который потом будет

использоваться тобой же или другим программистом. Если написать все в Header -е то тебе придется все include-ы которые будет использовать твой класс пихать в свой header файл...А теперь представь что тому программисту который будет использовать твой интерфейс совсем неохота чтоб у него в программе после инклуда твоего .h файла появился например list или stdio.h хотя бы потому что list это девичья фамилия его тещи которая так ненавящиво напоминает ему что новый год хочешь не хочешь а придется провести с вышеупомянутой родственницей да еще и поздравлять ее с праздником и целовать ее прыщавую физиономию..ну не любит он тещю, бывает такое...а ты как бы заставляешь его инклудить все то что нужно тебе, а быть может совсем не нужно ему...(вполне возможно что у него тоже есть класс list или функция принтф)...
Вобщем ВСЕ функции желательно писать в CPP файле...

Цитата

Представь, тебе надо написать интерфейс. Короче говоря класс который потом будет использоваться тобой же или другим программистом. Если написать все в Header -е то тебе придется все include-ы которые будет использовать твой класс пихать в свой header файл...А теперь представь что тому программисту который будет использовать твой интерфейс совсем неохота чтоб у него в программе после инклуда твоего .h файла появился например list или stdio.h хотя бы потому что list это девичья фамилия его тещи которая так ненавящиво напоминает ему что новый год хочешь не хочешь а придется провести с вышеупомянутой родственницей да еще и поздравлять ее с праздником и целовать ее прыщавую физиономию..ну не любит он тещю, бывает такое...а ты как бы заставляешь его инклудить все то что нужно тебе, а быть может совсем не нужно ему...(вполне возможно что у него тоже есть класс list или функция принтф)... Вобщем ВСЕ функции желательно писать в CPP файле...smile

Представляете, если бы книги так писали.

Это разделение пошло ещё с C, там в заголовочных файлах описывалис прототипы функций, а их реализации обычно скрывались (путём создания библиотек обьектных файлов), тоже самое делается и сейчас.

Суть же самого разделения на декларацию и имплементацию состоит в том, что декларация (т.е. описание классов) меняется довольно редко, а вот реализация в процессе разработки изменяется часто.

Такое разделение даёт несколько очевидных преимуществ.

1. Скрытие реализации (не скажу, что для всех преимущество , однако для разработчиков коммерческих библиотек так точно)
2. Возможность т.н. прекомпиляции (или раздельной компиляции).
3. Стандартизация интерфейсов.

поясню.
С первым понятно...

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

Код

// code.h class Code {     Code();     DoCode(); }; // code.cpp #include "code.h" void Code::Code() {   // реализация } void Code::DoCode() {  // реализация }

и есть несколько участков в которых он используется

Код

#include "code.h" .... void Section1::func() {   Code cd;   cd.DoCode(); } .... void Section2::func() {   Code* pCode = new Code();   ...   pCode->DoCode();   ...   delete pCode; }

Все эти три класса расположены в отдельных файлах и при компиляции образуется три байткодовых файла (Code.obj, Section1.obj, Section2.obj)

А теперь представим что код в классе Code постоянно изменяется (А интерфейс не изменяется). Однако, поскольку Section1 и Section2 ссылаются лишь на прототип класс и поэтому вне зависимости от того, как будет изменён класс Code, эти два класса перекомпилироваться не будут.

Обратная ситуация в случае с реализацией, непосредственно в заголовках. Как известно C++ компилятор (в отличии от компилятора Java) при компиляции некоторого кода руководствуется только набором директив include, всё что будет таким образом найдено, используется при компиляции. Поэтому при описании реализации в заголовочных файлах, для каждого из частков кода (читай файла), который использует эти методы будет создаваться своя копия кода данных методов.(во закрутил ). Вообщем код описанный в заголовочных компилируется вновь всякий раз, когда будет использован.

Однако есть исключения: inline подстановки, которые и должны каждый раз включаться в том месте где используются (именно поэтому они обязательно должны быть определены в заголовочных файлах). Шаблонные классы, тоже обязательно должны быть определены в заголовках, т.к. для них всё равно в каждом отдельном случае необходима компиляция.

И третье.. связано с первым и вторым. Для некоторых реализации возможно сгенерировать интерфейсы доступа по байткоду, обычно эти интерфейсы получаются в виде заголовочных файлов.

Цитата(NiJazz @ 15.12.2004, 10:22)

Представляете, если бы книги так писали.

Может, лучше бы тогда было?

azesmcar все правильно написал.
Кстати, interface и implementation появились в паскале в связи с появлением модулей, а не с поддержкой ООП.

Разделение программы на заголовки (интерфейсы) и реализацию - та же самая инкапсуляция (один из ее видов). Header'ы - это public, cpp - private.
Кстати, если уж на то пошло, то модуль - это просто синглтон. У него есть интерфейс, есть реализация, и существует он в единственном экземпляре.

Цитата

Может, лучше бы тогда было?

сомневаюсь. писать, все-таки, правильно нужно.

А что у него неправильно

пунктуация

Да и про тещу горестно было читать.
А вообще пошёл флейм.

Да уж, действительно хватит.