On Tue, May 4, 2010 at 7:05 AM, David Cournapeau <[email protected]> wrote: > On Mon, May 3, 2010 at 7:23 PM, Austin Bingham <[email protected]> > wrote: >> Hi everyone, >> >> I've recently been developing a python module and C++ library in >> parallel, with core functionality in python and C++ largely just >> layered on top of the python (with boost.python.) In some cases, >> however, for performance reasons, the C++ API "reaches into" the >> python code via the C API, and this tends to happen very often with >> numpy-related code. >> >> As a result, I'm using the numpy C API a lot in my C++ library. To >> make a long story short, I'm finding that there are many places where >> I need to include numpy headers in my own headers (e.g. when a >> template class uses part of the numpy API.) If the symbol I want in my >> header is in ndarrayobject.h, it seems that I'm obligated to define >> PY_ARRAY_UNIQUE_SYMBOL because that file includes __multiarray_api.h. >> However, defining that macro in a header file seems like a bad idea >> because of potential conflicts with headers from other libraries. > > You don't need to define PY_ARRAY_UNIQUE_SYMBOL to include any public > numpy header - it seems that you are trying to avoid getting > PyArray_API defined, but I don't understand why. > > PY_ARRAY_UNIQUE_SYMBOL should only be used when you want to split your > extension into separately compilation units (object files).
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'. >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.) As things stand, there's no way for 'util.h' to use NPY_TYPES (part of the latter set) without affecting users of the former set. It seems easy enough to make the latter set available in their own header to help avoid these kinds of problem. Austin _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
