Menu
▾
▴
corelinux-develop
|
From: Christophe Prud'h. <pru...@MI...> - 2000-09-29 20:17:54
|
I think that we should rely on libtool for the default implementation.
I mean that the library to be loaded may have the following
name "plugin" and the real name(built internally) is "libplugin.la" which
is a file generated by libtool. this file contains informations about
dependencies.
Loading a .so is ok but the dependencies won't be met automatically so you
have to do it "by hand" which is boring and ugly.
From my experience of loading c++ libraries, you provide a c function with
"C" external linking:
the developper of the library "plugin" has to provide something like
extern "C" {
void* init_plugin()
{
return new plugin;
}
}
Moreover what about library destruction?
what if the library loader is destroyed while some libraries are still loaded?
will we use some kind of reference counting to keep track of the libraries
which are loaded
- +1 when the library sends a message that the object has been created
successfully
- -1 if destroyed
that is we should implement some kind of event notification system
(mediator/observer?)
thoughts?
As you may have noticed, I am willing to do the default library
implementation :). I would like to have it working as quickly as possible.
regards
C.
--
Christophe Prud'homme |
MIT, 77, Mass Ave, Rm 3-243 | The first thing we do, let's kill
Cambridge MA 02139 | all the lawyers.
Tel (Office) : (00 1) (617) 253 0229 | -- Wm. Shakespeare,
Fax (Office) : (00 1) (617) 258 8559 | "Henry VI", Part IV
http://augustine.mit.edu/~prudhomm |
Following the hacker spirit
|
|
From: Frank V. C. <fr...@co...> - 2000-09-30 00:34:58
|
Christophe Prud'homme wrote:
>
> I think that we should rely on libtool for the default implementation.
>
> I mean that the library to be loaded may have the following
> name "plugin" and the real name(built internally) is "libplugin.la" which
> is a file generated by libtool. this file contains informations about
> dependencies.
>
> Loading a .so is ok but the dependencies won't be met automatically so you
> have to do it "by hand" which is boring and ugly.
>
> >From my experience of loading c++ libraries, you provide a c function with
> "C" external linking:
> the developper of the library "plugin" has to provide something like
>
> extern "C" {
> void* init_plugin()
> {
> return new plugin;
> }
> }
>
> Moreover what about library destruction?
> what if the library loader is destroyed while some libraries are still loaded?
> will we use some kind of reference counting to keep track of the libraries
> which are loaded
> - +1 when the library sends a message that the object has been created
> successfully
> - -1 if destroyed
> that is we should implement some kind of event notification system
> (mediator/observer?)
>
> thoughts?
The ld takes care of reference counting.
>
> As you may have noticed, I am willing to do the default library
> implementation :). I would like to have it working as quickly as possible.
Yes, but what of the type information? This was the purpose of the meta
class, and more importantly, the Library Load abstraction. Work with me
on the metaclass, it will be a much more rewarding and flexible
framework.
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package
|
|
From: Christophe Prud'h. <pru...@MI...> - 2000-10-01 20:23:49
|
> Yes, but what of the type information? This was the purpose of the meta
> class, and more importantly, the Library Load abstraction. Work with me
> on the metaclass, it will be a much more rewarding and flexible
> framework.
what would you want me to do ?
what about inheritance?
in mt simple metaclass stuff I propagate the information through a macro
if I want to have this feature for a derived class (ths parent class must
have it of course)
I add something like that to the class Class
Macro(Class, Parent class);
then I have things like
- getClassName()
- isTypeOf()
- isA()
where Macro is defined like this
#define Macro(thisClass,superclass) \
virtual const char *getClassName() const {return #thisClass;};\
static bool isTypeOf(const char *type) \
{ \
if ( !strcmp(#thisClass,type) ) \
{ \
return 1; \
} \
return superclass::isTypeOf(type); \
} \
virtual bool isA(const char *type) \
{ \
return this->thisClass::isTypeOf(type); \
}
as you can see what I did is simple but was ok for what I want.
what do you plan to do about this?
this==inheritance
C.
--
Christophe Prud'homme |
MIT, 77, Mass Ave, Rm 3-243 | Un prud'homme était un homme
Cambridge MA 02139 | d'honneur et de valeur,
Tel (Office) : (00 1) (617) 253 0229 | sage et loyal.
Fax (Office) : (00 1) (617) 258 8559 | -- Chateaubriand
http://augustine.mit.edu/~prudhomm |
Following the hacker spirit
|
|
From: Frank V. C. <fr...@co...> - 2000-10-01 22:04:04
|
Christophe,
This is basically the idea (that your macro has) only with a bit more
information reflection details.
In the short term, class MetaType is also a factory for type instances
(which enables any kind of memory management one would desire to
override). So, take Integer for example:
{
IntegerPtr aInt = Integer::getMetaType()->create();
*aInt = 78;
Integer::getMetaType()->destroy(aInt);
}
In the longer term, we need to support things like attributes so that
Persistence can get and set data to and from the data
stores.
Also, the Ontology will allow you to traverse the hierarchy of MetaTypes
to instantiate types that you want. So when, for example, the Function
Library Loader needs to execute something from a shared library, it can
reason with the ontology for the appropriate return types, instantiate
one for the return, and viola!
Of course it is more involved. Did you see the NIHCL object.hpp I sent
you? That is the long term goal (in general functionality, not the way
it looked.)
From that point, we can add utilities which scan a ELF *.so file and
generate all the ExecutionObjectDefinitions automagically (even at run
time if we implement it so).
Generally, I was going to do most of the work with macro expansions.
This week you will see the fruits of labor start to appear.
I am working on the neccessary
Christophe Prud'homme wrote:
>
> > Yes, but what of the type information? This was the purpose of the meta
> > class, and more importantly, the Library Load abstraction. Work with me
> > on the metaclass, it will be a much more rewarding and flexible
> > framework.
> what would you want me to do ?
> what about inheritance?
> in mt simple metaclass stuff I propagate the information through a macro
> if I want to have this feature for a derived class (ths parent class must
> have it of course)
>
> I add something like that to the class Class
>
> Macro(Class, Parent class);
>
> then I have things like
> - getClassName()
> - isTypeOf()
> - isA()
>
> where Macro is defined like this
>
> #define Macro(thisClass,superclass) \
> virtual const char *getClassName() const {return #thisClass;};\
> static bool isTypeOf(const char *type) \
> { \
> if ( !strcmp(#thisClass,type) ) \
> { \
> return 1; \
> } \
> return superclass::isTypeOf(type); \
> } \
> virtual bool isA(const char *type) \
> { \
> return this->thisClass::isTypeOf(type); \
> }
>
> as you can see what I did is simple but was ok for what I want.
>
> what do you plan to do about this?
> this==inheritance
>
> C.
> --
> Christophe Prud'homme |
> MIT, 77, Mass Ave, Rm 3-243 | Un prud'homme était un homme
> Cambridge MA 02139 | d'honneur et de valeur,
> Tel (Office) : (00 1) (617) 253 0229 | sage et loyal.
> Fax (Office) : (00 1) (617) 258 8559 | -- Chateaubriand
> http://augustine.mit.edu/~prudhomm |
> Following the hacker spirit
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/mailman/listinfo/corelinux-develop
--
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package
|
