include «other_code.cpp» посреди кода

class A {
    int a;
    public:
    void method();
};

int
main(int argc, char *argv[])
{
    A a;
    return 0;
}

Не наводит на мысль?

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

Интересно, а ты хоть попробовал это сделать?

Как и в сишке, хидер класса только объявляет форварды, а методы класса это всего лишь замангленные функции. Если оба твоих сорца заинклудят один и тот же хидер, но реализуют разные части набора методов, то своя часть разрезолвится как местная, а не своя как внешняя. Внешние зависимости разрезолвятся при линковке.

Обычно это всё значит, что пора выделять новые сущности.

Реализацию класса можно хоть по ста файлам раскидать. А такое оформление не очень хорошее, но имеет право на жизнь при использовании автогенерированного кода. Например таблица с обработчиками команд может быть вынесена в отдельный файл и создаваться при сборке скриптом духа:

echo "static command commands[] = {"
for x in *; do
  if [ -d "$x" ]; then
    echo "{ \"$x\", &do_$x },"
  fi
done
echo "NULL};"

Класс или структура command определяется раньше, глобально определенной ее делать нет смысла.

А про первый вопрос я бы подумал, что other_code.cpp генерится генератором и инклудится во избежание возни со статичной обвязкой.

Я бы подумал «Что за упорота?!»

Обычно .cpp инклюдят ради шаблонов либо инлайновых функций которые в них находятся. Иначе будут ошибки типа type redefinition.

В первую очередь я бы подумал, что other_code.inc содержит развёртывания макроса, вроде

error(unexpected_token, true, false, "expected %1, got %2"),
error(undeclarated_id, true, true, "%1 is not declarated in this scope"),
// etc...

Что бы вы подумали, если бы читая код, написанный другим разработчиком, увидели следующее:

Что кто-то не умеет пользоваться макросами. Как вариант - вставляется сгенерённый машиной код, но это всяко плохая практика.

В связи с этим, кстати, второй вопрос: как грамотно вынести кусок громоздкого файла в другой файл, если хочется просто разделить один сиплюсплюсный исходник на два? Ну, например, допустим что есть класс, надо его реализацию сделать не в одном файле, а в двух, часть функций-членов в одном файле, часть — в другом.

Не надо этого делать. Не поверю, что класс может быть НАСТОЛЬКО огромен, чтобы понадобилось размещать его в двух файлах. Если так, то лучше будет разбить сам класс.

как грамотно вынести кусок громоздкого файла в другой файл, если хочется просто разделить один сиплюсплюсный исходник на два? Ну, например, допустим что есть класс, надо его реализацию сделать не в одном файле, а в двух, часть функций-членов в одном файле, часть — в другом.

Разносить разные сущности по разным классам, а классы по разным файлам.

Не наводит :(

Даже и не пытался, просто стало интересно. А что, они нормально соберутся? o0

А, то есть можно так разнести класс? Отлично, спасибо.

Я вообще ближе к сям, этот вопрос мне был интересен с теоретической точки зрения.

А что, они нормально соберутся?

Да.

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

Не поверю, что класс может быть НАСТОЛЬКО огромен

Ну, меня интересовал вопрос только с теоретической точки зрения. На практике, вероятно, действительно

лучше будет разбить сам класс

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

Я подумал примерно то же самое.

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

Зато в хидере все методы будут. Инклудишь хидер в оба cpp файла и будет тебе счастье.

В общем случае это нормально, например, other_code может быть просто сгенерирован чем-нибудь уровнем по-выше плюсов.

Я подумал бы, что разработчик чудак. На букву «М».

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

Можно. И что, что нету? Компилятору вообще плевать, определена какая-то функция, или только объявлена. Линкеру не плевать, но линкер понятия не имеет, что функции относятся к одному классу.

обычно в гуях есть куча безмозглого копипастнутого/автогенерящегося кода, в середину которого втыкается что-то осмысленное. Вот это «осмысленное» стоит выделить в отдельный файл, а gui-фреймворк пусть об этом лучше не знает и продолжает генерить портянки в основной файл. В C# для этого сделали partial class definition: http://msdn.microsoft.com/ru-ru/library/wa80x488.aspx

Ужасно, никогда с таким не сталкивался. Все генерилки, которые я писал или видел, генерили и *.cpp, и *.h. Вставлять cpp внутрь cpp — жесть.

Я почти так делал. На простом C вектор инициализации для массива структур. В основном файле:

struct xxx[] = {
#include "some.c"
}

Это говнокод, хотя таким методом некоторые пользуются в разработке с Qt.

в том подключенном .cpp был написан код реализации пары функций

Дай угадаю, там присутствовало слово «inline», да?

Не поверю, что класс может быть НАСТОЛЬКО огромен, чтобы понадобилось размещать его в двух файлах.

Видал god-класс на 20к строк реализации + 8к строк хедера. Да, от него еще наследовался класс с еще 15к/4к :)

Ну, например, допустим что есть класс, надо его реализацию сделать не в одном файле, а в двух, часть функций-членов в одном файле, часть — в другом.

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

Обычно это всё значит, что пора выделять новые сущности.

+1

В чём вообще прикол, делать #include<xxx.CPP>, тем более посреди кода O_o

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

Ооо, я так тоже делал. :)

В связи с этим, кстати, второй вопрос: как грамотно вынести кусок громоздкого файла в другой файл

Не вижу проблемы. Берешь и делишь код на два файла.

Эти файлы ведь нельзя будет собирать по очереди

Можно. Вот наоборот, объявление класса нельзя будет раскидать по разным файлам так, чтобы половина методов объявлена в одном файле, другая в другом.

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

Чего это вдруг нельзя? Очень даже можно. На выходе будет два объектника с неразрешёнными зависимостями, которые потом благополучно хавает компоновщик. Ты можешь следать объявление класса в одном .h, а количество .cpp - хоть по файлу на метод. Qt, например, этим хаком вовсю пользуется.

Вот в языках со строгой модульностью (Object Pascal, например) такой фокус уже не пройдёт.

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

Но даже это сильно коробит если не в самом начале файла.

В плюсовом коде видел реализацию класса в котором количество методов перевалило все разумные пределы и от объёма кода начинали тупить иде/редакторы. Причём, логически там ничего нельзя было разнести. Сделали file.cpp и file1.cpp с комментариями в каждом.