I have the below SWIG Interface file structure that I feel is invalid. The int func(usigned char key[20]) resides in headerThree.h. When I leave in the %include "HeaderThree.h" I get a duplicate int func(SWIGTYPE_p_unsigned_char key);. If I remove the %include "HeaderThree.h", the other functions do not show up in the generated Example.java file..only the int func(short[] key) does. I would like to configure the SWIG .i file to not have the
func(SWIGTYPE_p_unsigned_char key) function but to have the rest of the functions included in HeaderThree.h. Any ideas?
%module Example
%{
#include "HeaderOne.h" //has constants and type definitions
#include "HeaderTwo.h" // has an #include "HeaderOne.h" and its own C apis
#include "HeaderThree.h" // has an #include "HeaderOne.h" and its own C apis
%}
%include "arrays_java.i"
int func(unsigned char key[20]);
%include "HeaderOne.h" //has constants and type definitions
%include "HeaderTwo.h" // has an #include "HeaderOne.h" and its own C apis
%include "HeaderThree.h" // has an #include "HeaderOne.h" and its own C apis
The problem here is that when you say %include it is as though you pasted the contents of the file directly at that point (i.e. asked SWIG to wrap it all). This means SWIG has seen both versions of func, the one you explicitly told it about and the one that actually exists in the header you %included.
There's a couple of ways you can fix this, although having the extra overload kicking around doesn't really do any harm, it's just noisy and messy.
Hide the declaration of func in the header file from SWIG using #ifndef SWIG. Your header file would then become:
#ifndef SWIG
int func(unsigned char *key);
#endif
When you %include that header file SWIG won't see this version of func - that's not a problem though because you explicitly told it about another version (which is compatible for the purposes of SWIG)
Use %ignore to instruct SWIG to ignore this version of func specifically. The SWIG module file then becomes:
%module Example
%{
#include "HeaderOne.h"
#include "HeaderTwo.h"
#include "HeaderThree.h"
%}
%include "arrays_java.i"
int func(unsigned char key[20]);
// This ignore directive only applies to things seen after this point
%ignore func;
%include "HeaderOne.h"
%include "HeaderTwo.h"
%include "HeaderThree.h"
You could also change the actual declaration and definition of func in the header file and the place it's actually implemented in your code to use unsigned char[20] instead of unsigned char*.
Related
In C , we can easily access file using fprintf() and fscanf() as shown below:
fp = fopen(“forces1.txt”, “w”);
for(h=0;h<147;h++)
{
fprintf(fp, “%f %f %f\n”, ForceX[h], ForceY[h], ForceZ[h]);
}
But I am using CUDA and my variables ForceX[h] etc are of type cuDoubleComplex. I want to ask two things:
Whether I am allowed to use frintf and fscanf in CUDA, if not then how to access files.
What will be the format specifier used in place of %f as my variable is not float.
From here:
in cuComplex.h (which is in the CUDA include directory in your CUDA install) we can see the following typedef:
typedef double2 cuDoubleComplex;
and double2 is a struct definition (in vector_types.h, same directory) that looks like this:
struct double2 {
double x,y;
};
So now your question is a C or C++ question. You can print the elements (.x, .y) of that struct easily enough using the %f format specifier.
Yes, you can use fprintf and fscanf in CUDA host code, just like you would in ordinary host code.
Most of my library is written with Cython in the "normal" C mode. Up to now I rarely needed any C++ functionality, but always assumed (and sometimes did!) I could just switch to C++-mode for one module if I wanted to.
So I have like 10+ modules in C-mode and 1 module in C++-mode.
The problem is now how Cython seems to handle complex numbers definitions. In C-mode it assumes I think C complex numbers, and in C++-mode it assumes I think C++ complex numbers. I've read they might be even the same by now, but in any case Cython complains that they are not:
openChargeState/utility/cheb.cpp:2895:35: error: cannot convert ‘__pyx_t_double_complex {aka std::complex<double>}’ to ‘__complex__ double’ for argument ‘1’ to ‘double cabs(__complex__ double)’
__pyx_t_5 = ((cabs(__pyx_v_num) == INFINITY) != 0);
In that case I'm trying to use cabs defined in a C-mode module, and calling it from the C++-mode module.
I know there are some obvious workarounds (right now I'm just not using C++-mode; I'd like to use vectors and instead use the slower Python lists for now).
Is there maybe a way to tell my C++-mode module to use C complex numbers, or tell it that they are the same? If there is I couldn't find a working way to ctypedef C complex numbers in my C++-mode module... Or are there any other solutions?
EDIT: Comments of DavidW and ead suggested some reasonable things. First the minimum working example.
setup.py
from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext
from Cython.Build import cythonize
extra_compile_args=['-O3']
compdir = {'language_level' : '3'}
extensions = cythonize([
Extension("cmod", ["cmod.pyx"]),
Extension("cppmod", ["cppmod.pyx"], language='c++')
],
compiler_directives = compdir
)
setup(cmdclass = {'build_ext': build_ext},
ext_modules = extensions
)
import cppmod
cmod.pyx
cdef double complex c_complex_fun(double complex xx):
return xx**2
cmod.pxd
cdef double complex c_complex_fun(double complex xx)
cdef extern from "complex.h":
double cabs(double complex zz) nogil
cppmod.pyx
cimport cmod
cdef double complex cpp_complex_fun(double complex xx):
return cmod.c_complex_fun(xx)*abs(xx) # cmod.cabs(xx) doesn't work here
print(cpp_complex_fun(5.5))
Then just compile with python3 setup.py build_ext --inplace.
Now the interesting part is that (as written in the code) only "indirectly" imported c functions have a problem, in my case cabs. So the suggestion to just use abs actually does help, but I still don't understand the underlying logic. I hope I don't encounter this in another problem. I'm leaving the question up for now. Maybe somebody knows what's happening.
Your problem has nothing to do with the fact, that one module is compiled as a C-extension and the other as a C++-extension - one can easily reproduce the issue in a C++-extension alone:
%%cython -+
cdef extern from "complex.h":
double cabs(double complex zz) nogil
def cpp_complex_fun(double complex xx):
return cabs(xx)
results in your error-message:
error: cannot convert __pyx_t_double_complex {aka
std::complex<double>} to __complex__ double for argument 1 to
double cabs(__complex__ double)
The problem is that the complex numbers are ... well, complex. Cython's strategy (can be looked up here and here) to handle complex numbers is to use an available implementation from C/CPP and if none is found a hand-written fallback is used:
#if !defined(CYTHON_CCOMPLEX)
#if defined(__cplusplus)
#define CYTHON_CCOMPLEX 1
#elif defined(_Complex_I)
#define CYTHON_CCOMPLEX 1
#else
#define CYTHON_CCOMPLEX 0
#endif
#endif
....
#if CYTHON_CCOMPLEX
#ifdef __cplusplus
typedef ::std::complex< double > __pyx_t_double_complex;
#else
typedef double _Complex __pyx_t_double_complex;
#endif
#else
typedef struct { double real, imag; } __pyx_t_double_complex;
#endif
In case of a C++-extension, Cython's double complex is translated to std::complex<double> and thus cannot be called with cabs( double complex z ) because std::complex<double> isn't double complex.
So actually, it is your "fault": you lied to Cython and told him, that cabs has the signature double cabs(std::complex<double> z), but it was not enough to fool the c++-compiler.
That means, in c++-module std::abs(std::complex<double>) could be used, or just Cython's/Python's abs, which is automatically translated to the right function (this is however not possible for all standard-function).
In case of the C-extension, because you have included complex.h as an so called "early include" with cdef extern from "complex.h", thus for the above defines _Complex_I becomes defined and Cython's complex becomes an alias for double complex and thus cabs can be used.
Probably the right thing for Cython would be to always use the fallback per default and that the user should be able to choose the desired implementation (double complex or std::complex<double>) explicitly.
I have two swig modules that share some common headers. I only want to %include the header in one but I want the other to be able to still treat the enums as integers (rather than classes) without fully %including it. Something kind of like this:
MyEnum.h
typedef enum {
One,
Two
} MyEnum;
LibOne.i
module() libOne
%{
#include "MyEnum.h"
%}
%include "MyEnum.h"
HeaderUsingMyEnum.h
#include <MyEnum.h>
MyEnum DoSomething(MyEnum &anEnum);
MyEnum &DoAnotherThing(MyEnum *anEnum);
LibTwo.i
module() libTwo
%{
#include "MyEnum.h"
#include "HeaderUsingMyEnum.h"
%}
%include "HeaderUsingMyEnum.h"
The problem is that swig then turns around and creates swig objects in LibTwo whereas LibOne just automatically treats the enums as unsigned ints. Then I have a mismatch between the two modules on what they think a MyEnum is.
Obviously simply %including MyEnum.h in libTwo works perfectly well but it's a lot of duplication. I also know I can write a bunch of MyEnum typemaps for LibTwo but I want to know if there is an 'automatic' way to do it, maybe with %apply or some such thing?
There are quite a few enumerated types in the main library and I'd love to have a simply way to just tell SWIG to just treat them as ints.
I guess I've been struggling to solve esoteric SWIG problems and didn't recognize when one came along that was actually simple. This seems to do the trick.
%include "typemaps.i"
%apply unsigned int { MyEnum };
I tried to do this:
thrust::zip_iterator<IteratorTuple> zip;
zip = make_zip_iterator(...)
That failed to compile, but when I did this:
typedef thrust::zip_iterator<IteratorTupe> ZipIterator;
ZipIterator zip = make_zip_iterator(...)
, my code compiled and did exactly what I wanted. My question is, why was the typedef required in this case? And is this usage of typedef specific to this context? I can post the rest of my code if somebody thinks the problem might have been elsewhere.
The reason this:
thrust::zip_iterator<IteratorTuple> zip;
zip = make_zip_iterator(...)
fails is because the thrust::zip_iterator has no default constructor. This is a sensible design choice because an uninitialised fancy iterator has no practical use. The version including the typedef works because the copy constructor is used during instantiation of the fancy iterator. It is not a property of the typedef itself.
[This answer has been assembled from comments and added as a community wiki entry to get this question off the unanswered queue].
I am trying to make a small interpreter using Flex and Bison.
Now I have two files: parser.l and parser.y. Usually, main function is put in parser.y file. What I want to do is to put the main function in a different file main.cpp which makes my package look neat.
#include "y.tab.h"
int main()
{
yyparse();
return 0;
}
But when I compile, I got an error:
undefined reference to `main'
So I know there is something wrong to include y.tab.h.
Could you someone to tell me how to do it?
Solution
I just figured it out:
add the following to your main.c file:
extern FILE *yyin;
extern FILE *yyout;
extern int yyparse(void);
SO noted:
I just figured it out: add the following to your main.c file:
extern FILE *yyin;
extern FILE *yyout;
extern int yyparse(void);
#Jonathan Leffler Noted
You don't really need yyin or yyout since you don't (yet) reference
them from the file containing main(). However, if you end up doing
work such as reading from files specified on the command line instead
of standard input, you may need them. It would be nice if Bison
generated a header with the appropriate declarations in it. The
y.tab.h file is not, however, the place for that information; it is
used to convey information between the parser and the lexical
analyzer, not between the application and the parser.