[gmpi] Re: Topic 3: Cross platform
- From: "Angus F. Hewlett" <amulet@xxxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 5 Mar 2003 12:32:45 -0500 (EST)
On Wed, 5 Mar 2003, Paul Davis wrote:
> the same thing happens on all *nix OS's systems i know. but that isn't
> enough. exception support and proper initialization of C++ DLL's can
> vary according to the compiler flags used for the *host*. if i compile
> the host with --no-exceptions to gain the approx 5% speed gain that
> this provides, then a plugin throwing an exception will likely cause
> the program to abort.
Even if the exception is caught within the plug..???
> there's also the horrendous problem with C++ that there is no standard
> ABI, and so you cannot run-time link code from the "wrong" compiler,
> where "wrong" can mean: wrong vendor, wrong version, wrong compile
> time flags.
Yeah, another good reason to use C as the basic interface.
> >OK... and as far as platform-specific goes, the library-loading phase will
> >be platform specific anyways, simply because the containers are
> >different...
>
> not necessarily. i wouldn't want anyone to use it, but libltdl exists
> to do run-time loading of DLLs on windows, macos, beos, irix, linux,
> os x and others.
hmm, but libltdl itself contains platform specific code on the individual
platforms, it's just a standardized interface to a lib. in the end, you
can't get away from platform specifics SOMEWHERE along the line.
> i can easily imagine completely platform independent code
> to load, create and initialize the DSP part of a plugin.
OK.. perhaps.. but by sticking with the standard containers we also keep
support for the standard compile tools. Using something new would probably
mean writing new linkers... etc... far too much work imho.
> i'm thinking of things like (as you mentioned): file i/o, mutual
> exclusion (lock-based and lock-free), access to & initialization of
> DSP resources, discovering associated plugin resources
> (cf. discussions on vst-plugins about determining the folder the
> plugin was found in), getting current time of day, getting current CPU
> configuration, getting CPU features, getting CPU utilization figures
> (perhaps) ...
> these are all things plugins may want to do, and we'd like them to do
> it in a platform-independent way.
I'm inclined to think that creating a standard API for GMPI that goes
beyond plug<->host communications is a bit of a risky step in terms of
design.. however if others think it's justified I could find it
acceptable.
Regards,
Angus.
----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules: Please stay on topic. You are responsible for your own
words. Please respect your fellow subscribers. Please do not
redistribute anyone else's words without their permission.
Archive: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
