I am in the process of re-writing a parser in order to make it reentrant. In that spirit, I am interested in passing a couple of functions to bison and then have bison pass them to lex also.
One of those functions is a callback which I use in my actions and the other one is the the function to be called by flex to get input data.
To do so, I have put this in my .y file:
%lex-param {void (*my_input)(void *, char*, int *, int)}
%parse-param {void (*my_input)(void *, char*, int *, int)}
%parse-param {void *(*my_callback)(void *, char *, int, struct YYLTYPE *, int, ...)}
Then, in my .l file I have declared:
#define YY_DECL int yylex (YYSTYPE *yylval_param, YYLTYPE *yylloc_param, yyscan_t yyscanner, void (*my_input)(void *, char*, int *, int))
The problem is that I think bison might have a bug when generating its code. When I try bo build, i get the following error:
tmp.tab.c: In function ‘yy_symbol_value_print’:
tmp.tab.c:4043: error: expected expression before ‘)’ token
If we visit that line we get this function:
static void
yy_symbol_value_print (FILE *yyoutput, int yytype, YYSTYPE const * const yyvaluep, YYLTYPE const * const yylocationp, yyscan_t scanner, void (*my_input)(void *, char*, int *, int), void *(*my_callback)(void *, char *, int, struct YYLTYPE *, int, ...))
{
FILE *yyo = yyoutput;
YYUSE (yyo);
YYUSE (yylocationp);
YYUSE (scanner);
YYUSE (int);
YYUSE (int);
if (!yyvaluep)
return;
YYUSE (yytype);
}
The first line with YYUSE(int) is the one throwing the error. As you can see, this function somehow receives the same arguments as yyparse, then it calls a macro called YYUSE() with the arguments received. I think that since two of my arguments are functions (with their arglist, as they have to be declared if I understand correctly) bison calls YYUSE() with the last argument of each of those function prototypes... as far as I know it should be USE(my_input) and USE(my_callback)...
I have a hard time believing this is really a bug, I mean, really, nobody has tried this until now? I find it hard to believe...
The YYUSE() calls are all over the generated files, even though I dont really know what they are for... So changing by hand is not really an option...
Has anybody done this successfully in the past? Is there something I am doing wrong?
Bison's parameter parser is a little primitive. It expects to see something like %param {type name}, and if it finds something more complicated, it may do the wrong thing. (type can be reasonably complicated; it can include const, *, and other such modifiers. But the name needs to be the last thing in the specification.)
This is documented in the Bison manual: (emphasis added)
Directive: %parse-param {argument-declaration} …
Declare that one or more argument-declaration are additional yyparse arguments. The argument-declaration is used when declaring functions or prototypes. The last identifier in argument-declaration must be the argument name.
A similar restriction applies to tagnames in a %union directive.
You can make your program more readable both for bison and for human readers by using typedefs:
Put this in a common header file:
typedef void (*InputFunction)(void *, char*, int *, int);
typedef void *(*CallbackFunction)(void *, char *, int, struct YYLTYPE *, int, ...);
Bison file:
%lex-param {InputFunction my_input}
%parse-param {InputFunction my_input} {CallbackFunction my_callback}
Flex file:
#define YY_DECL int yylex (YYSTYPE *yylval_param, YYLTYPE *yylloc_param, yyscan_t yyscanner, InputFunction my_input)
By the way, the intent of the YY_USE macro is to mark parameters as "used", even if they are not; this avoids compiler warnings in functions which happen not to use the arguments. It could be argued that it is the programmer's responsibility to ensure that arguments are either used or marked as unused, but that's not the approach bison happened to take. Regardless, non-conforming parameter declarations such as the one you provided will fail in other interesting ways, even without YY_USE.
Related
When calling hci_inquiry how do I know/control if responses are of type inquiry_info, inquiry_info_with_rssi or inquiry_info_with_rssi_and_pscan_mode?
As you can see in the file hci_lib.h, in the prototype, the fifth argument is a double pointer to your inquiry_info array of size num_rsp.
int hci_inquiry(int dev_id, int len, int num_rsp, const uint8_t *lap, inquiry_info **ii, long flags);
inquiry_info_with_rssi and inquiry_info_with_rssi_and_pscan_mode are quite different structures so if you mistakenly use them you will have unexpected results.
Ok, so I'm using C++ to make a library that'd help me to print lines into a console.
So, I want to override " "(quote operators) to create an std::string instead of the string literal, to make it easier for me to append other data types to that string I want to output.
I've seen this done before in the wxWidgets with their wxString, but I have no idea how I can do that myself.
Is that possible and how would I go about doing it?
I've already tried using this code, but with no luck:
class PString{
std::string operator""(const char* text, std::size_t len) {
return std::string(text, len);
}
};
I get this error:
error: expected suffix identifier
std::string operator""(const char* text, std::size_t len) {
^~
which, I'd assume, want me to add a suffix after the "", but I don't want that. I want to only use ""(quotes).
Thanks!
You can't use "" without defining a suffix. "" is a const char* by itself either with a prefix (like L"", u"", U"", u8"", R"()") or followed by suffixes like (""s, ""sv, ...) which can be overloaded.
The way that wxString works is set and implicit constructor wxString::wxString(const char*); so that when you pass "some string" into a function it is essentially the same as wxString("some string").
Overriding operator ""X yields string literals as the other answer.
I am using Cython for fast parallel processing of data, adding items to a shared memory linked list from multiple threads. I use __sync_bool_compare_and_swap, which provides an atomic compare and swap (CAS) operation to compare if the value was not modified (by another thread) before replacing it with a new value.
cdef extern int __sync_bool_compare_and_swap (void **ptr, void *oldval, void *newval) nogil
cdef bint firstAttempt = 1
cdef type *next = NULL
cdef type *newlink = ....
while firstAttempt or not __sync_bool_compare_and_swap( <void**> c, <void*>next, <void*>newlink):
firstAttempt = 0
next = c[0]
newlink.next = next
This works very well. However, now I also want to keep track of the size of the linked list, and want to use the same CAS function for the updates, however, this time it is not pointers that need to be updated but an int. How can use the same external function twice in Cython, once with void** parameter and once with an int* parameter?
EDIT
What I have in mind is two separate atomic operations, in one atomic operation I want to update the linked list, in the other I want to update the size. You can do it in C, but for Cython it means you have to reference the same external function twice with different parameters, can that be done?
CONCLUSION
The answer suggested by DavidW works. In case anyone is thinking to use a similar construction, you should be aware that when using two separate update functions there is no guarantee these are processed in sequence (i.e. another thread can update in between), however, if the objective is to update a cumulative value for instance to monitor progress while multithreading or to create an aggregated result that is not used until all threads are finished, CAS does guarantee that all updates are done exactly once. Unexpectedly, gcc refuses to compile without casting to void*, so either define separate hard-typed versions, or you need to cast. A snippet from my code:
in some_header.h:
#define sync_bool_compare_and_swap_int __sync_bool_compare_and_swap
#define sync_bool_compare_and_swap_vp __sync_bool_compare_and_swap
in some_prog.pxd:
cdef extern from "some_header.h":
cdef extern int sync_bool_compare_and_swap_vp (void **ptr, void *oldval, void *newval) nogil
cdef extern int sync_bool_compare_and_swap_int (int *ptr, int oldval, int newval) nogil
in some_prog.pyx:
cdef void updateInt(int *value, int incr) nogil:
cdef cINT previous = value[0]
cdef cINT updated = previous + incr
while not sync_bool_compare_and_swap_int( c, previous, updated):
previous = value[0]
updated = previous + incr
So the issue (as I understand it) is that it's __sync_bool_compare_and_swap is a compiler intrinsic rather than a function, so doesn't really have a fixed signature, because the compiler just figures it out. However, Cython demands to know the types, and because you want to use it with two different types, you have a problem.
I can't see a simpler way than resorting to a (very) small amount of C to "help" Cython. Create a header file with a bunch of #defines
/* compare_swap.h */
#define sync_bool_compare_swap_voidp __sync_bool_compare_and_swap
#define sync_bool_compare_swap_int __sync_bool_compare_and_swap
You can then tell Cython that each of these is a separate function
cdef extern from "compare_swap.h":
int sync_bool_compare_swap_voidp(void**, void*, void*)
int sync_bool_compare_swap_int(int*, int, int)
At this stage you should be able to use them naturally as plain functions without any type casting (i.e. no <void**> in your code, since this tends to hide real errors). The C preprocessor will generate the code you want and all is well.
Edit: Looking at this a few years later I can see a couple of simpler ways you could probably use (untested, but I don't see why they shouldn't work). First you could use Cython's ability to map a name to a "cname" to avoid the need for an extra header:
cdef extern from *:
int sync_bool_compare_swap_voidp(void**, void*, void*) "__sync_bool_compare_and_swap"
int sync_bool_compare_swap_int(int*, int, int) "__sync_bool_compare_and_swap"
Second (and probably best) you could use a single generic definition (just telling Cython that it's a varargs function):
cdef extern from "compare_swap.h":
int __sync_bool_compare_and_swap(...)
This way Cython won't try to understand the types used, and will just defer it entirely to C (which is what you want).
I wouldn't like to comment on whether it's safe for you to use two atomic operations like this, or whether that will pass through a state with dangerously inconsistent data....
Trying to create LPCTSTR conversion operator for my class:
AuthData::operator LPCTSTR() const
{
const char* k = "aaaa";
return k;
}
Error: return value type does not match the function type
Why it don't match?
If Unicode Character Set is enabled, LPCTSTR type is const wchar_t *.
#Edit
You can read about these types here:
https://softwareengineering.stackexchange.com/a/194768
In a Multi-Byte project, LPCTSTR is defined as LPCSTR, which is CONST CHAR*, so your code should compile (if it is in fact non-Unicode).
NEVER mix TCHARs with chars! At least - not without a conversion. Your declaration practically implies that TCHAR is defined as char, so why would you suggest to the readers that you are TCHAR-aware (since you are not)?
I am getting a strange set of error in my Visual Studio 2010 compiler.
I am getting the errors of
error C2572: redefinition of default parameter
error C2011: 'class' type redefinition
I have checked thoroughly and I know very well that in the function definition, I have not given the default parameter values and I have given default parameter value only in function prototype in the header file.
Also, I am very much sure that no two class has been given the same class name.
Please can anybody tell me what could be the other reasons for getting these set of errors?
I have not got the exact reason why it was happening, but I have overcome it by using some simple techniques.
I used function overloading concept to avoid default parameter list. It will cause in duplication of code, but it has proved to be very effective.
So something like this
void myFunction( int, char * = '\0', char * = '\0' );
would become something like this
void myFunction( int );
void myFunction( int, char * );
void myFunction( int, char *, char * );
In this example, code is getting duplicated two times but it seems to be only work around solution.
Next, for the strange class type redefinition error, I was instantiating the class variable in many files. So, I removed that feature of instantiation everywhere and went with global variable something like this.
File named as myHeader.h
#include "myFile.h"
myClass myObj;
And in all the other files
#include "myHeader.h"
myObj.function1( );
myObj.function2( );