организация библиотеки(внешние модули)

[Пепел Феникса]

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

появилась мысль сделать так:
имеем длл с классами(классы экспортированы(точнее методы, но не суть) и открыты(не скрыты через кота)), они не для прямого использования.
и длл интерфейс, она уже использует те длл с классами, и предоставляет простые функции(по принципу кота), интерфейс при необходимости подгружает(*) нужные длл-классы.
+ проблем так же не будет
+ экономится память процесса при неполной загрузке библиотеки
- больше файлов и немного больше веса

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

кто что подскажет?

[f.hump]

- по мере дополнения библиотеки, длл растет(и соответственно будет занимать зря память при потреблении)
+ экономится память процесса при неполной загрузке библиотеки

Не понимаю я этого.
Вроде 2Гб виртуального пространства под рукой.
Это ж какой размер библиотеки должен быть?

[Пепел Феникса]

2ГБ, то это да, но кто знает нужды целевого приложения

да и даже, хрен с ней с памятью тогда уж(хотя и разрастаться зря тоже не хочется)

[pproger]

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

пс. не называй пимпл чеширским котом. pimpl - pointer to implementation, все ясно и понятно.
кстати, покажи как реализовал кросплатформенную работу с библиотеками, хочется посмотреть, так ли понял мою идею (а она красива)

[f.hump]

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

не знаю про что это, но в целом когда хочется сделать класс-длл, объявляют итерфейс

class myBadAssClass {
public:
 virtual int DoSomething(void *) = 0;
 virtual void DoNothing() = 0;
}

а библиотека эскпортирует страшный метод

myBadAssClass * CreateBadAss();

ну этот метод инициализирует все, что хотелось инициализировать в рамках myBadAssClass

[Пепел Феникса]

подгрузкой в реалтайме?
или же связи разрешать будет линковщик?

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

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

у меня сейчас время теории.(сегодня в код решил не лезть, просто размышления, потому и создавал темы)
а это старый, которым не занимался полгода(решил немного сменить деятельность)

не знаю про что это, но в целом когда хочется сделать класс-длл, объявляют итерфейс

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

просто почему я хотел сделать отдельно, ибо например три библы:
Windows, Console, Sockets
понятное дело что не каждому приложению нужны все три.

PS: сейчас понял что написал много лишнего в вопросе.
если надо, завтра переформулирую.

[BOBAH13]

Сообщение от Пепел Феникса

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

появилась мысль сделать так:
имеем длл с классами(классы экспортированы(точнее методы, но не суть) и открыты(не скрыты через кота)), они не для прямого использования.
и длл интерфейс, она уже использует те длл с классами, и предоставляет простые функции(по принципу кота), интерфейс при необходимости подгружает(*) нужные длл-классы.
+ проблем так же не будет
+ экономится память процесса при неполной загрузке библиотеки
- больше файлов и немного больше веса

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

кто что подскажет?

Трудно что-то сказать, т.к. отсутствует конкретика вопроса. Но я все же выскажусь:
1. Один файл, наследование... - хорошо конечно, но раз у вас ООП, мы то не знаем чего у вас там за классы и что они будут делать, нужно сначала построить иерархию, спроектировать все сущности и разделить на классы, чтобы выполняли свои конкретные задачи.
2. Кроссплатформенность - тоже отлично, тогда имеет смысл определить, какие классы (с их методами) платформенно зависимы. Далее определиться, кроссплатформенность какая? runtime, на этапе компиляции или еще чего придумали? Если на этапе компиляции, то как обычно в С, через #define #ifdef и т.д. погнали соответствующие вызовы, если рантайм, то вынести класс вне основной библиотеки и подгружать динамически, например исходя из имени файла (ну добавить постфикс например или префикс win32 и т.п.).

Я может не то говорю, но просто перечитал несколько раз сообщение ваше, ну не смог понять, как уж слишком все в теории как по мне.

[Пепел Феникса]

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

вопрос в общем то можно сформировать гораздо короче, стоит ли менять литую длл, на набор [куча класс-длл + длл-функциональный интерфейс]
иерархия примерно получается такая(пакет->классы):

                        Base->Object
                         /    |     \
IO->Stream,FileStream,etc     |     String->String,Encoding
                      Files->File,Directory

надеюсь везде ровно..
это не учитывая зависимостей между классами(ну и не все естестенно тут)

вот я и хочу каждый из пакетов вынести отдельно.

PS: вообще сейчас на свежую голову, затея мне вполне нравится, но мало ли, совет опытных товарищей не помешает(не фигню ли я придумал)

[Пепел Феникса]

короче, закройте тему, пожалуйста.

сделаю так как хочу, если что вернусь к тому что было.

[Stilet]

ИМХО я бы все в одну ДЛЛ сложил...
Ты идешь путем дотнета и это хорошее решение, но удобное ли - вот вопрос.
С одной стороны для программы не все ДЛЛки понадобятся, если ты не все будешь использовать, с другой стороны как обновлять устаревшие родительские ДЛЛ (несущие твой Base->Object), ведь это может повлиять на всю иерархию вниз.

Я бы всетки в одну ДЛЛ сложил...