On 05/04/2010 04:38 PM, Austin Bingham wrote: > > I admit I'm having trouble formulating questions to address my > problems, so please bear with me. > > Say I've got a shared library of utilities for working with numpy > arrays. It's intended to be used in multiple extension modules and in > some places that are not modules at all (e.g. C++ programs that embed > python and want to manipulate arrays directly.) > > One of the headers in this library (call it 'util.h') includes > arrayobject.h because, for example, it needs NPY_TYPES in some > template definitions. Should this 'util.h' define > PY_ARRAY_UNIQUE_SYMBOL? Or NO_IMPORT? It seems like the correct > answers are 'no' and 'yes', but that means that any user of this > header needs to be very aware of header inclusion order. For example, > if they want to include 'arrayobject.h' for their own reasons *and* > they want NO_IMPORT undefined, then they need to be sure to include > 'util.h' after 'arrayobject.h'.
I still don't understand why you cannot just include the header file as is (without defining any of NO_IMPORT/PY_ARRAY_UNIQUE_SYMBOL). >From what I can see, the problem seems to be a conflation of two sets > of symbols: those influenced by the PY_ARRAY_UNIQUE_SYMBOL and > NO_IMPORT macros (broadly, the API functions), those that aren't > (types, enums, and so forth.) numpy headers are really messy - way too many macros, etc... Fixing it without breaking API compatibility is a lot of work, though, cheers, David _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
