paragui-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [paragui-users] the dll low down


From: Alexander Pipelka
Subject: Re: [paragui-users] the dll low down
Date: 04 Jun 2002 19:26:11 +0200

Unfortunately this won't fix it :))

Every application linking to the shared lib creates its own instances of
the static vars. The only real solution would be to rework ParaGUI
completely and move all static vars (and most static functions) into
classes.

Nevertheless it works if you're linking with a shared lib version of
ParaGUI.

Alex

Am Die, 2002-06-04 um 19.14 schrieb Andrew Ford:
> Can you fix this by placing static variables in their
> own anonymous namespace:
> 
> namespace {
>     static pgWhatever lookImHidden;
> }
> 
> Stroustrup's book mentions something about it...
> 
> Andrew.
> 
> --- Alexander Pipelka <address@hidden> wrote:
> > Hmm,...
> > 
> > There's one thing that came to my mind after your
> > last email:
> > Are you linking your dll's statically to ParaGUI (I
> > think i read this in
> > your CWproject readme) ?
> > 
> > It won't work this way.
> > 
> > Why ?
> > 
> > Because ParaGUI hold a whole bunch of static
> > variables (the globall app
> > object, widgetlists, messagemaps,...).
> > If you link it statically every dll will be a
> > seperate ParaGUI instance.
> > 
> > Solution ?
> > Create a ParaGUI dll and link it with your main app
> > and your "plugin"
> > dlls.
> > 
> > Alex
> > 
> > Am Die, 2002-06-04 um 17.29 schrieb Keith Swyer:
> > > ok, i'll geive you some nice details.....
> > > 
> > > - i am using a base class that all the dlls are
> > based from
> > > 
> > > class Area{
> > > public:
> > >     virtual void FillArea(void *data, void *data2)
> > = 0;
> > > private:
> > >     friend class dll_object_ref<Area>;
> > >     virtual void destroy()=0;
> > > };
> > > 
> > > - in the dlls i create i use the Area base class,
> > then call a macro
> > > FACTORY_ENTRY(newclass, name)
> > > which then calls this....  allowing us to have a
> > clean way to access the
> > > names without the c++ mangled crap.
> > > (externc is a macro for extern "c" and dllfunc is
> > just the export )
> > > #define FACTORYFUNC( base , the_class , prefix ,
> > classid ) \
> > >   EXTERNC DLLFUNC base* DLLCALL prefix##classid(
> > void )    \
> > >     { return new the_class; }
> > > 
> > > - these are the DLL support classes: dll_sentinel,
> > dll_object_ref, and
> > > dll_object_ptr.
> > > Class dll_sentinel is responsible for ensuring
> > that the DLL is resident
> > > during the sentinel's lifetime. It keeps track of
> > both the DLL name and the
> > > handle to that DLL. The first time a dll_sentinel
> > is created, it asks the OS
> > > to load the DLL, and the OS sets the DLL's
> > reference count to one. Every
> > > time another dll_sentinel loads the same DLL, the
> > OS increments that DLL's
> > > reference count. When each dll_sentinel is
> > destroyed, it asks the OS to
> > > close the DLL. The OS actually just decrements the
> > DLL's reference count,
> > > and unloads the DLL only when that count reaches
> > zero.
> > > dll_object_ref contains a dll_sentinel, a pointer
> > to an object residing in
> > > the DLL, and a reference count. When a
> > dll_object_ref is constructed, it
> > > finds the appropriate function in the DLL and uses
> > it to initialize its
> > > pointer. When the dll_object_ref is destroyed, it
> > deletes the object pointed
> > > to.
> > > 
> > > dll_object_ptr is similar to std::auto_ptr, except
> > that its ownership
> > > semantics are slightly different. Copying one
> > dll_object_ptr to another does
> > > not cause one of them to become invalidated or to
> > lose ownership of the
> > > underlying object. Because dll_object_ptr takes
> > advantage of
> > > dll_object_ref's reference counting scheme, the
> > underlying object gets
> > > destroyed only when all of its dll_object_ptrs are
> > destroyed.
> > > 
> > > Now that i hopefully have you all confused  :)  i
> > don't have a way that each
> > > dll instanciates themselves automatically yet, but
> > right now my factory
> > > template allows you to instantiate by referring to
> > the name of the
> > > class.....anyway, this all works fine and i can
> > call _object->FillArea
> > > fine, but inside of that function in the dll i
> > cannot use any of the paragui
> > > functions.
> > > 
> > > 
> > > 
> > > well, i hope this isn't too much to wrap your
> > heads around as i know i'm
> > > getting a litte off paragui specific (but i am
> > planing to add this somehow
> > > to pg) any help would be great. I know this isn't
> > probably the best way to
> > > do what i'm doing, but i've had to figure this all
> > out by looking around the
> > > net, and i'm only new to using and making dlls... 
> >  :)
> > > 
> > > 
> > > 
> > > --Keith
> > > 
> > > 
> > > 
> > > _______________________________________________
> > > paragui-users mailing list
> > > address@hidden
> > >
> >
> http://mail.freesoftware.fsf.org/mailman/listinfo/paragui-users
> > 
> > 
> > 
> > 
> > _______________________________________________
> > paragui-users mailing list
> > address@hidden
> >
> http://mail.freesoftware.fsf.org/mailman/listinfo/paragui-users
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! - Official partner of 2002 FIFA World Cup
> http://fifaworldcup.yahoo.com
> 
> _______________________________________________
> paragui-users mailing list
> address@hidden
> http://mail.freesoftware.fsf.org/mailman/listinfo/paragui-users






reply via email to

[Prev in Thread] Current Thread [Next in Thread]