This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Dynamic Libraryes, C++ and Objective-C
- From: "Lawrence Crowl" <crowl at google dot com>
- To: "Bruno Moreira Guedes" <thbmatrix at gmail dot com>
- Cc: gcc-help at gcc dot gnu dot org
- Date: Fri, 4 Jan 2008 15:41:30 -0800
- Subject: Re: Dynamic Libraryes, C++ and Objective-C
- References: <3fdd6ce00801011903x1b1b63egcd479de40c0c5e08@mail.gmail.com>
On 1/1/08, Bruno Moreira Guedes <thbmatrix@gmail.com> wrote:
> Hello People,
>
> I'm highly interested in developing a "very-pluggable API", to offer a
> "Java API-like"(just LIKE hehehe) for C++. So, I asked myself "how
> could I dynamic load classes?". During my research about how to
> construct that, I break into that step, and it's getting too hard to
> pass...
>
> After a little research, I heard about a 'ugly' method which consists
> of creating a virtual/pure-virtual and class using a helper function
> to make the new/delete operations.
>
> But I want to "split" the API into a base library, statically linked
> with the base libraries, and the "pluggable parts", where each part
> consists of a set of many classes. So, creating a virtual class for
> each class don't make sense...
>
> Researching anymor I heard about a Objective-C ability of creating and
> modifying classes during the runtime. But I don't know Objective-C
> very-well and I don't know how to 'mix' it with C++ code... As an
> alternative, if someone could help-me about using GCC to mix that, I'm
> grateful...
>
> But returning to the main problem, I want to use the headers which I
> have of the API parts, of course... And the I get the idea of letting
> the symbols to be resolved during the library loading stage, and not
> during the compile time...
> There's anyway to don't resolve the symbols during the compile-time???
Your best bet is probably to define a simple function that is a factory
for implementation classes derived from the interface's abstract base
classes. Each plug-in would define the factory.
--
Lawrence Crowl