avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: Has anyone considered C++ Framework?
Date Fri, 17 Aug 2001 03:35:02 GMT
I didn't have an immediate need.  Java does seem to have more
advantages in many areas.

Peter Donald wrote:
> 
> On Fri, 17 Aug 2001 02:18, Berin Loritsch wrote:
> > I know Avalon's charter says we have a Java Framework.
> > Avalon's Framework is very generic, and would easily be
> > converted to C++.  I would like to experiment with such
> > a beast--but was wondering if anyone else had any
> > feelings one way or the other with that.
> 
> Well I haven't considered doing it with Apache Avalon a lot of my previous
> work in this domain was C/C++ based. My history of framework + phoenix style
> apps is basically
> 
> 98     - *unnamed* module+kernel system (native C++ system)
> 98-99  - ACR System            (native C++ kernel, scriptable by java)
> 99     - My Avalon System      (native C++ kernel with java plugins)
> 00     - Telanon System        (java kernel with native C++ plugins)
> 00-01  - Apache Avalon System  (pure java)
> 
> You may notice a trend away from C++ above ;) The reason is that to write a
> comparable system you have to implement a lot of underlying support. In my
> case I had to be portable between linux/win which probably added to the
> burden.
> 
> First you need to find or implement a cross platform debugging library - this
> is almost essential. Basically this does stacktraces, debugger breaks,
> asserts, etc. However to achieve the same safety that I get for free in java
> my code will often something look like
> 
> void myClass::myMethod( int *pParam1, int param2 )
> {
>   guard(myClass::myMethod);
> 
>   assert( NULL != pParam1 );
>   assert( MemSys::isValidPointer( pParam1 ) );
> 
>   ...do work code here...
> 
>   unguard(myClass::myMethod);
> }
> 
> After that you need to write a decent memory subsystem that checks
> allocations. For every leaked allocation get a stack trace at allocating
> position. Most of my code was pre-STL stability/acceptance but if you adopt
> that you will also need to write your own allocators and possibly a decent
> garbage collector for small items.
> 
> After that you should implement a decent component system. Probably like COM.
> So instead of doing
> 
> if( component instanceof Configurable )
> {
>   (Configurable(component)).configure( ... );
> }
> 
> you would do
> 
> IConfigurable *pConfigurable =
>   (IConfigurable *)QUERY_INTERFACE( myComponent, IConfigurable );
> if( NULL != pConfigurable )
> {
>   pConfigurable->configure( ... );
> }
> 
> The remainder of work is creating registrys of one sort or another. These are
> simple if you work all your magic in statically bound apps. However as soon
> as you start using DLLs the issues become painful. Each interface needs to
> keep references to it's "parent" or "factory" and play the IncRef/DecRef
> game.
> 
> The advantages of C++ include;
> * superior GUI toolkits (either go native or QT for XP)
> * fast startup time
> * easy integration with existing products
> 
> The disadvantages of C++;
> * sooooooooooooo much more work
> * longer to develope even after you have the base
> * code becomes 90% defensive code 10% content
> 
> If you are interested I have a bunch of links for equivelent projects to what
> we are doing and pointers to some fundamental toolkits/runtimes. Just ping me
> and I will send em.
> 
> --
> Cheers,
> 
> Pete
> 
> *-----------------------------------------------------*
> * "Faced with the choice between changing one's mind, *
> * and proving that there is no need to do so - almost *
> * everyone gets busy on the proof."                   *
> *              - John Kenneth Galbraith               *
> *-----------------------------------------------------*
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: avalon-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: avalon-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: avalon-dev-help@jakarta.apache.org


Mime
View raw message