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

Вот главная программа, к которой надо подключить функции отдельными файлами:

и вот одна из функций, ее надо поместить в файл clearall.cpp

Пробовал инклюдить по-разному, но выдается unresolved symbol и т.д.
Как сделать?

ты наверное забыл *.срр в проект подключить

Покажи полный код файла срр, со всеми инклудами...

Первый код это cpp файл? Если да - то не будет работать, когда компилится второй код компилятор не знает объявления класса List. Объявление класса надо вынести в отдельный .h файл и инклудить его.
 Можно конечно инклудить и cpp файлы, только вот вопрос зачем?

Anikmar, только тогда их компилить не надо (инклюдимые файлы). Иначе линкер ругнётся мол "symbol .. defined in ...".

Вот я и спрашиваю Зачем? Я сказал, что теоретически можно инклудить cpp файлы - это чистая правда.

Общепринятый подход:

Класс объявляется и загоняется в .h файл

Все реализации запихиваются в cpp файл (можно, конечно и в несколько - только зачем, опять таки не понимаю)

Когда реализация используется вместе с объявлением - лично я никогда это не использую (ну не нравится мне это)

И уж тем более я никогда не объявляю класс в cpp модуле - это на мой взгляд ерунда получается.

Anikmar, некоторые классы-посредники удобней объявлять в cpp файле. Наружу тогда не торчит этот "сервисный" класс. 

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

Но это чисто мое мнение, конечно, на вкус и цвет...

Вот пример из cppшника.

Честно говоря, приведенный пример не особо впечатлил. Больше похоже на заплатку. Не могу сказать, что сходу можно посмотреть что делает nsg::console::ResponseHandler, а класс Handler - больше похож на временный наворот, предназначенный для дальнейших усовершенствований. Как только они начнут реализовываться - то либо будет создан для Handler отдельный файл либо данный код перестанет быть удобоваримый.

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

На самом деле спор ни о чем.

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

Это мой стиль, я просто его придерживаюсь.

Anikmar, согласен с тобой. Действительно внутренние классы предпочитаю объявлять в как вложенные в прайват.

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

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

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

Это просто как я привык, не напрягаю никого на то, что это стандарт. Мне просто кажется это удобнее.