C++ class ->> .cpp && h.

.h - только декларация класса .cpp - выполнение

Получается, что описывать только в .h - неправильнне ИМХО, если уж делать всё в 1-м файле, то в .cpp

Посмотри на STL и ужаснись :)

зависит от класса. Если это темплейт то только .h. Если в классе есть инлаин-функции то все они должны быть в .h, а не инлаин-функции в .cc . Вообче, если класс не предназначен для использования другими модулями (например, не есть часть публичного интерфейса библиотеки), тогда однозначно в .cc

Ну и причем здесь STL? Там же не классы описываются...

Чревато багами типа следующего:

// a.h class A { public: int a(); }; A::a() {return 666;}

// b1.cpp #include "a.h" /* Тра-ля-ля */

// b2.cpp #include "a.h" /* Тра-ля-ля-2 */

При линковке b2.o и b1.o линковщик скажет что я тебя две функции A::a() (а оно так и есть :).

Еще замечание:
Если написать

// a.h
class A { public: int a() {return 666;} };

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

Вот про это я и спрашивал : а какие будут вызваны осложнения если у меня будет описан класс и у меня там всего три метода описанных инлайн(все описанно в .h).

Только время компиляции. Больше никаких минусов не вижу. ;)

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

Всем спасибо большое!!!. Мораль уяснил.

>мораль такая:

Во многом это вопрос стандартов кодирования.

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

Такой подход вообще убивает основную идею stl как таковую в результате ты получаешь программу, написанную на гремучей смеси си с не знаю чем. Самый конструктивный подход - использовать все доступные в языке средства, но с умом и по назначению.

> Такой подход вообще убивает основную идею stl как таковую

AFAIK, писать шаблоны целиком в хедерах обязывает не С++ как таковой, а трудность реализации ключевого слова export, которое *позволило бы* их определять в отдельном С++-файле. g++ export не поддерживает, но вроде есть компиляторы, которые его поддерживают.