Re: RTTI and exceptions between plugins (solution)
Re: RTTI and exceptions between plugins (solution)
- Subject: Re: RTTI and exceptions between plugins (solution)
- From: Thomas Engelmeier <email@hidden>
- Date: Wed, 8 Feb 2006 23:37:13 +0100
Hi Steve,
If your exceptions are defined in a framework that both plugins
link to then you are probably OK. You need to make sure that the
exception is not completely inline (i.e. at least some of it is
defined in a .cpp file in the common framework).
Still an *ouch* - it simply adds some other day of work, dependency
and configuration management for something "free" with CodeWarrior.
if( typeid theMessage) == typeid(X) )
{
... do something
}
The comparison will fail, as even though typeid theMessage).name()
== typeid(X).name(), &typeid(theMessage) != &typeid(X).
The same could potentially happen with exceptions.
IMO it is pretty much the same when you catch an exception "by name",
e.g.
try
{
plugin->do_something_that_throws()
}
catch( const plugininterface_exception& ex ) // handler needs to
know the RTTI type of ex
{
// handle it
}
This problem on the whole will not happen with applications that
have public plugin interfaces (e.g. Photoshop). Here, the
interface tends to be small and well defined, and the innards of
the plugins are largely private.
Photoshop had in the public available SDKs always a pure C interface
with tons of function pointers.
Indesign is a completely different beast, with an OpenDoc derived
architecture and heavy C++ usage, including RTTI, exceptions,
polymorphism, MI et. al. The SDK with its some-hundrets of classes
and thousands of methods consumes already in the CW variant a quarter
to half a GB.
I used it as an illustrative example, the other architectures I'm
working with are under NDA.
In our case we use plugins differently - they integrate as if
they are a full part of the program, largely the user doesn't know
about the plugins, they are really just a way for us to divide up
the functionality into easily managed chunks (which can be
distributed across the team).
Once again, see Indesign. The Application is basically an Plug-In
manager (+ some embedded licensing), what the user percepts as the
App are Plug-Ins. One thing I am working on is inbetween, while not
as well-defined as ID, also rather modular..
Regards,
Tom_E
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden