site_archiver@lists.apple.com Delivered-To: pro-apps-dev@lists.apple.com Thanks, Micah On May 22, 2007, at 10:39 AM, Paul Miller wrote: Does it help if you stick it into unique namespaces? Thanks guys. Micah On May 22, 2007, at 10:19 AM, Matt Rhodes wrote: On May 22, 2007, at 9:47 AM, Micah Sharp wrote: <http://lists.apple.com/mailman/listinfo/xcode-users> Hi Micah. We had to make each templated C++ class have a unique name. For example, we have 2 FxPlugs: Stackwerks and 3D Flag. These FxPlugs share a zxArray class (which is a template). We had to make the name "zxArray" unique for the two FxPlugs. We do it with the following at the top of our zxArray.h: #ifdef FLAG #define zxArray zxArrayClassFL #endif #ifdef STACKWERKS #define zxArray zxArrayClassSW #endif We had to do this for all of our template C++ classes. I don't know if this is the only solution, but it works for us. Matt Rhodes Zaxwerks, Inc. -- 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/site_archiver%40lists.ap... Not sure, it might, but then we'd have to use macros again just like unique function names, since it is a single template function in a header file shared by various plugins projects. Micah Sharp wrote: Yup, thanks Matt, indeed it only seems like the template function had the problem, not regular functions. I'm pretty sure our intermediate files build to different locations as well. A guy here actually just noticed that making the template function static also seemed to avoid the problem in case that is useful. I recall we were told that with Objective-C we needed to have unique class or interface names, but does this hold true for functions as well? We have 3 plugins that all share a templated function, and it REALLY seems like one plugin is calling the function compiled a 2nd plugin. We think this because, if we add "return 0" at the top of the function, but only rebuild one plugin, the code still executes! If we rename the function to something unique, then it correctly returns 0 and does nothing. Another interesting thing is we had been having problems stepping into the code to debug, but after the rename, it suddenly has no problem at all. Is that possible? Micah, The problem we talked about is only with Objective-C class names. It doesn't affect method names, as those are always resolved at runtime in Objective-C, and it doesn't affect C or C+ + function, method, or class names, as they are resolved at compile or link time. However, you can still run into a problem that looks like the same thing, but isn't, with C or C++. I believe what's happening is that the linker is finding an older version of the library containing templated method your code is calling. If you do a full clean and rebuild of your filter, you'll probably find that it works correctly. I think this occurs when you have 1 directory that you put all of your intermediate files into, regardless of the project that they belong to. But I'm not positive. Do you have your project set up to output intermediate files to some common directory that is shared with other projects? You might ask on the xcode user's list, too. I know this has come up before. You can sign up here: But basically, it's an Xcode configuration issue, and not a language problem, as far as I know. Darrin I'll have to check Darrin's suggestion, but I'm pretty sure we compile each project into separate directories. Our code would react the same as yours did until we did this. Now things work just fine. Note that we only had to do this with our template classes -- not regular C++ classes. --------------------------------------------------------------------- --- _______________________________________________ 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/paul%40fxtech.com This email sent to paul@fxtech.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/micah% 40redgiantsoftware.com This email sent to micah@redgiantsoftware.com This email sent to site_archiver@lists.apple.com