Re: Static data member behaviour in release builds
Re: Static data member behaviour in release builds
- Subject: Re: Static data member behaviour in release builds
- From: Jack Nutting <email@hidden>
- Date: Wed, 17 Aug 2005 10:24:42 +0200
On 8/16/05, Steve Baxter <email@hidden> wrote:
> Hi,
>
> I have a strange problem. I have a class that has a static data
> member. This class is implemented in a shared framework and is
> linked to by an application and several other plugins (implemented as
> bundles).
>
> In debug mode everything works fine - the app and plugins all share
> the same static data member.
>
> In release mode this fails to work properly - it looks like each app
> and plugin gets its *own* copy of the static data member. This then
> causes our application to fail (the static is actually a pointer to a
> singleton which is initialised by the app and accessed by the app and
> all the plugins).
>
> The only differences I can see between the release and debug builds are:
>
> - Optimisation on in release mode
> - Release strips dead code
> - In debug mode the plugins, app and framework are "side by side"
> - In release mode the plugins, app and framework are assembled into
> the app's bundle
>
> I am a bit stumped by this. So far I have not been able to debug a
> release build - if you click build and debug it builds the release
> app and then runs the debug version. Anyone got any ideas?
I can only guess why that's happening, perhaps something to do with
how symbols are being exported from the framework. But, I have an
idea for a workaround: make an accessor for this in your application,
either a function or method of some existing class, so that plugins
can grab the application's "version" of the static data instead of
asking the framework for it directly.
--
// jack
// http://www.nuthole.com
_______________________________________________
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