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]
