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.
Related
I am working at understanding the petsc4py sources. In them one finds many ctypedef declarations of the following form:
ctypedef <type> <typename> "<C typename>"
for instance the following:
ctypedef char* PetscMatType "const char*"
or
ctypedef struct PetscMatStencil "MatStencil":
PetscInt k,j,i,c
(In this second case MatStencil is a type that will be known to C at compile time because of its definition in a PETSc header file.)
I have not been able to find any explanation in the Cython documentation that explains this use of a quoted string in a ctypedef statement. (I gather from context that it is a hint to cythonize to implement the Cython type being defined with the named C type.) Can anyone tell me where to find this documented?
More generally, is there anywhere a comprehensive Cython reference? The main documentation I know of is that at cython.readthedocs.io. This is helpful, but it is not a comprehensive reference. For instance, if you search it for ctypedef, you find a bunch of examples, but none of the syntax I asked about above. What you do not find there is a comprehensive definition of ctypedef syntax.
There isn't a document that's a more comprehensive reference than the documentation you linked. It actually does have what you're asking about in it, although I suspect you need to know what you're looking for to find it (unfortunately): https://cython.readthedocs.io/en/latest/src/userguide/external_C_code.html#resolving-naming-conflicts-c-name-specifications:
For special cases where namespacing or renaming on import is not enough, e.g. when a name in C conflicts with a Python keyword, you can use a C name specification to give different Cython and C names to the C function at declaration time. Suppose, for example, that you want to wrap an external C function called yield(). If you declare it as:
cdef extern from "myheader.h":
void c_yield "yield" (float speed)```
It then goes on to show other examples of structs and variables being renamed (but not specifically typedefs).
Essentially the assumption is that usually when you wrap something in Cython you want to use the same name in Cython as you do in C. However sometimes that doesn't work and this "quoted string" syntax lets you specify a different name that matches your C code.
It's a useful trick to know about because it often lets you work round Cython limitations - for example when wrapping a single variant of a heavily templated C++ class without exposing the whole template hierarchy. In these cases I suspect that the const in const char was confusing Cython, and that the author wanted to use MatStencil as the name in the Python interface (so needed a different name for the C interface). Lying to Cython about small details is often helpful...
I am reading this post about time.startTimer declaration and definition.
From the answer, time.startTimer is declared in src/time/sleep.go
as follows:
func startTimer(*runtimeTimer)
And its definition is in src/runtime/time.go as follows:
func startTimer(t *timer) {
if raceenabled {
racerelease(unsafe.Pointer(t))
}
addtimer(t)
}
So it seems that you can declare a function in one .go file and implement it in another .go file. I tried the same way, for example, declare a function in a.go and implement it in b.go, but it always failed when go run a.go. Is that the correct way to do so? How can I declare a function that is implemented in another .go file? There is no import in either sleep.go or time.go. How does Go do it?
Thanks
If you look on the line above the startTimer body, you will see a special directive for the go compiler:
//go:linkname stopTimer time.stopTimer
From the compile command documentation
//go:linkname localname importpath.name
The //go:linkname directive instructs the compiler to use “importpath.name” as the object file symbol name for the variable or function declared as “localname” in the source code. Because this directive can subvert the type system and package modularity, it is only enabled in files that have imported "unsafe".
Since SWIG can't parse the __attribute__((packed)) on some C structs I'd like to wrap, I work around this by putting a
#define __attribute__(x)
in my .i file.
When will this come and bite me?
This is actually perfectly sane. SWIG doesn't need to know anything about the layout of the structs you're wrapping in order to be able to generate correct code. (It doesn't even need to know about all the members they contain even).
The reason for this is that the code which is generated is largely just marshaling data. In C you can legally write:
void show_a(const struct foo *instance) {
printf("%s", instance->b);
}
Regardless of whether foo was defined as:
struct foo {
double a;
char *b;
}
or
struct foo {
char *b;
double a,c;
int xyz;
}
The only place where the packing/alignment matters is when creating new structs. This is handled correctly though also, provided you don't also hide the attribute from the C compiler itself, because the generated C wrapper code will be using the real definition and not the pseudo one that you showed in the interface file.
It's a little bit clunky, but you can convince yourself of this as required by reading through the generated wrapper.
The general answer is that you can lie to SWIG itself quite a lot and it'll all work out alright in the end when the C compiler sees the generated code and reconciles it with the real definitions/declarations.
In the specific case the short answer is: so long as you only put that #define in the .i file and then only in a place where it doesn't get passed out to your generated module_wrap.c you're fine.
I have some C source code and want to wrap it in Cython. Now, the problem is, that there is a structure called print, and externing it throws a syntax error.
cdef extern from "foo.h":
struct print:
# ...
Same problem would appear when an attribute or a function or alike is called like a keyword.
cdef extern from "foo.h":
struct foo:
bint print
print(char*, int)
Is there a way to work around this, without modifieng the source? Maybe some technique that replaces a proxy-name with the real-name in the source-file ?
I think the solution you are looking for is something along the lines of:
cdef extern from "foo.h":
struct print "MY_print":
double var "MY_var"
print.var will then be defined by:
MY_print.MY_var
This way you can rename structs, functions, unions and enums from the header file. The names are converted when Cython compiles your code into C code.
The relevant part of Cython documentation can be found here.
I have two cuda kernels imageFlow() and cornerDetect(), defined in their individual cu files. They share a common global function, convolute1D(), which should rightfully have been in its own cu file as well. I had to place it, the implementation - not just the definition of convolute1D, in a header file convolution.h. This is then included in both cornerDetect.cu and imageFlow.cu, in order to use it from both kernels. This is because everything must be in the "same compilation unit".
Now the problem is that after compilation, convolute1D is actually defined in both imageFlow.obj and in cornerDetect.obj, since the included header had the actual implementation of the function.
This means that the final linker stage conplains about convolute1D being defined multiple times.
One solution would be to always use namespaces, but this that THE solution? It seems more like patching up the problem. I still have the implementation for convolute1D multiple times in the final binary, and what if I have some reason to use the same namespace for both my imageFlow and cornerDetection?
What about use extern definition?
// convolution.h
extern "C" void convolution1D() {
...
}
// imageFlow.cu
extern "C" void convolution1d();
// call the function when you need
convolution1D();
Same approach for cornerDetect.cu file.