site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Ah, these are C++ classes. Are your static instances defined like this? shared.h: class MyStuff { static MyStuff* theStuff; }; or like this? notshared.cpp: static MyStuff* theStuff; This might shed some light on your problem as well... http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntim... - Paul On Jun 25, 2008, at 5:44 PM, Paul Miller wrote: -- Paul Miller | paul@fxtech.com | www.fxtech.com | Got Tivo? _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/pschneider%40apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Pro-apps-dev mailing list (Pro-apps-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/pro-apps-dev/site_archiver%40lists.ap... Say I have a C++ class GlobalStuff in each one, and it's declared statically. The second one to load is calling into the methods of the instance in v1, even though they are declared statically. This doesn't happen with similar code in other hosts. The first one might not work the way you want with the default compiler settings. Paul Schneider wrote: Hi Paul, FWIW - I've got some classes in both, and the second one to load is calling into the code from the first one to load. Is there a way to keep each one from seeing the classes/code in the other? there's no way to prevent this in Objective C at the moment (google for "flat namespace"). Defining common classes in one plugin and having other plugins counting on that plugin to be loaded is probably asking for trouble. The two ways to get around this problem are: 1) if you can, put all of your plugin classes into a single bundle. We use this technique ourselves; I can explain how it works if you'd like. 2) if you can't do #1, put the common classes in a shared framework, and have both plugins link to the framework. Really, the only reason not to do #1 is if the two plugins are two separate products, sold separately, and the user could legitimately have one installed but not the other. But it sounds like if that were the case, what you're doing wouldn't work (plugin B depends on plugin A, right?). I should have been more clear. They are independent plugins that happen to have some C++ classes in each that are named the same. Say I have a C++ class GlobalStuff in each one, and it's declared statically. The second one to load is calling into the methods of the instance in v1, even though they are declared statically. This doesn't happen with similar code in other hosts. This email sent to pschneider@apple.com This email sent to site_archiver@lists.apple.com