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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
