Как скрыть базовый класс

[USBLexus]

Может быть вопрос немного ламерский 
Есть у меня класс у него есть базовый класс который тоже написал я. Базовый класс у меня вынесен из проекта. Когда я наследую от базового класса я указываю h файл базового класса в include но при компиляции линкер выдает unresolved external на методы базового класса. Чтобы этой ошибки не было приходится включать базовый класс в проект.
Вопрос как унаследовать от базового класса не включая его в проект?

[Alf]

1. Что значит "Базовый класс у меня вынесен из проекта"? Он вынесен в DLL, находится в объектной библиотеке, ...?

2. Фраза " при компиляции линкер выдает unresolved external" также звучит загадочно. Я так понял, сама компиляция проходит нормально, ошибка появляется только про компоновке? Или не так?

[USBLexus]

1. Что значит "Базовый класс у меня вынесен из проекта"? Он вынесен в DLL, находится в объектной библиотеке, ...?
Здесь файлы BaseClass.h и BaseClass.cpp не являются частью проекта, не подключены к нему
2. Фраза " при компиляции линкер выдает unresolved external" также звучит загадочно. Я так понял, сама компиляция проходит нормально, ошибка появляется только про компоновке? Или не так?
Компиляция проходит нормально, ошибка возникает при компоновке

[Гром]

USBLexus
1. При выключении файла из проекта он не компилируется, отсюда и проблема с unresolved external, что означает, отсутствие тела функции при известном прототипе.
Для этого необходимо включать файл с телом ф-ии в проект.

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

Какая цель преследуется???

[Alf]

Если просто выкинуть тело класса из проекта, компоновщик не сможет разрешить ссылки на него, само собой.

Можно поместить этот класс в статическую библиотеку, а потом указать ее в списке для компоновки.

[Алексей++]

USBLexus , ну дык - не подключены - ты подключи их в дерево проекта - добавь в папки проекта через визард, а не только скопировав в папку проекта

и всё пролезет

[USBLexus]

USBLexus
1. При выключении файла из проекта он не компилируется, отсюда и проблема с unresolved external, что означает, отсутствие тела функции при известном прототипе.
Для этого необходимо включать файл с телом ф-ии в проект.

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

Какая цель преследуется???

Цель преследуется - избежать нагромождение классов с Class Wizardе. Вынести класс в DLL хм... геморойно... А как это делается Где можно почитать? А если  я вынесу откомпиленый класс в DLL я смогу от него наследовать например в Дельфи  или Билдере?

[USBLexus]

А можно как-нибудь откомпилировать отдельно класс как obj и подключить его?

[USBLexus]

USBLexus , ну дык - не подключены - ты подключи их в дерево проекта - добавь в папки проекта через визард, а не только скопировав в папку проекта

и всё пролезет

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

[Алексей++]

USBLexus а зачем?

[Alf]

Пардон, нормально цитировать не получается. Я сегодня на компе с Mozill'ой, цитирование почему-то не работает.

"А если  я вынесу откомпиленый класс в DLL я смогу от него наследовать например в Дельфи  или Билдере?"

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

Даже просто использовать класс из одной среды в другой напрямую не удастся ввиду name mangling, а это штука платформенно-зависимая. Можно, конечно, объявить класс как extern "C", но в этом случае будут проблемы с перегруженными методами (ради которых name mangling и вводился).

[npak]

Если .NET не подходит, то можно воспользоваться COM, так как в COM унифицированы операции вызова методов и передачи данных.

[Alf]

А разве наследование в COM поддерживается? Насколько я понял, USBLexus хочет не просто использовать внешний по отношению к проекту класс, а именно наследовать от него.

[Гром]

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

Т.е. это ИМХО и даже не ИМХО две разные проблемы
1. Как на С++ под виндой и студией написать ДЛЛ для подключения в Дельфи и Билдере. Это одна проблема.
2. Как избавится от уже готовых и отлаженых модулей из списка в билдере - это вторая проблема.

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

первая проблема имеет несколько различных решений в зависимости от задачи.
Первое решение было найдено в моей теме как подключать билиотеку без знания имен функций или типов указателей на класс.
Объявлено простое решение создавать одну экспортную функцию как extern "C"  в которой переприсваивать указатели на нужные функции с помощью структуры поинтеров.

[npak]

А разве наследование в COM поддерживается? Насколько я понял, USBLexus хочет не просто использовать внешний по отношению к проекту класс, а именно наследовать от него.

Не поддерживается, совершенно верно.  Именно по этой причине в Майкрософт пошли на разработку .NET.  Но до разработки .NET COM был единственным надёжным способом переиспользования объектно-ориентированного кода в разных средах.

С .NET, кстати, тоже не всё так гладко, как принято говорить.  Для достижения межязковой совместимости требуется, чтобы код соответствовал ряду требований, которые кратко именуются CLS Compliance.

Если надо настоящее Си++ наследование в Visual Studio и Builder, то наиболее предпочтительным мне кажется вынести все базовые классы в библиотеку и сделать две сборки библиотеки -- одну для Visual Studio, другую для Builder.  ИМХО, немного усложняется сборка и поддержка, но зато не надо лепить компиляторо-зависимые корявости.

[USBLexus]

штошшшшшшш... Значит буду копать в сторону DLL
Жалко конечно что не получится перенести классы на Билдер и Дельфи, было бы круто)

[USBLexus]

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

[Алик]

"Цель преследуется - избежать нагромождение классов с Class Wizardе"
Для решения проблемы отображения лишних классов в class view (в .NET это, вроде, так называется)
нужно объявить класс (или группу классов) в своем пространстве имен. Потом можно смело подключать исходники библиотеки (и .h, и .cpp) в проект - все ее объявления буду в подузле с названием этого пространства имен. а если в самом конце хедера библиотеки написать "using namespace <имя_пространства_имен>, то использование пространства имен будет совершенно прозрачно для пользователей библиотеки.

[ChaoticCube]

>USBLexus
Только что совершенно случайно обнаружил такую весчь))) что если методы базового класса перенести в h а сам класс сделать шаблонным  а cpp файл удалить то все отлично подключается и компилируется без добавления в дерево Правда насколько это удобнее DLL надо еще подумать...

Абсолютно верно. Если делать полностью ин-лайн методы - то все прокатывает. Если тебя печалит писать в  хидер определения методов, то создавай файл *.inl и определяй методы в нем. Тогда после тебе потребуется только написать #inlcude "*.inl" там где эти методы нужны.

[ChaoticCube]

Но на полностью inline -овых классах ты вряд ли напишешь серьезные вещи (допустим рекурсия в ин-лайн вообще невозможна). Смотри в общем по задаче. Если ин-лайн компоновка тебя не слишком устроит - то длл конечно же решение более оптимальное.

[USBLexus]

Алик. Хм. интересно Стоит попробовать!)
ChaoticCube Честно говоря не хотелось бы связываться с inline классами)