I have created a small parser in c using flex and bison. The parser writes the result to some global variables and the caller function reads it from there.
I am trying to package my parser as a php extension. From what i understand from the php documentation true global variables are not recommended because they are not thread-safe and i have to use module globals instead.
In order to use module globals you have to pass in the function TSRMLS_DC as its last argument.
To you know if i can modify the yyparse to accept TSRMLS_DC as an argument. Or if there is another way to access global variable?
I wouldn't use global variables, but use a more modern parser generator that is also reentrant. Look for instance how I've done it for the meta extension (I use a slightly changed lemon and re2c).
Related
I'm trying to write some CMake code in a relatively complex project and I have a module that internally includes another module. The problem is, whenever I include my module, all of the functioned defined in the module it internally includes become available at a global level! This effectively is polluting my global namespace with a bunch of functions I didn't explicitly ask for.
For example:
# CMakeLists.txt
# Include my module
include(MyModule)
# Call a function from my module
my_module_function()
# HERE IS THE PROBLEM -- functions from "AnotherModule" are visible here!
# This call works
another_module_function()
Inside my module:
# MyModule.cmake
# Include another module
# - This other module is written and supported by someone else so I can't modify it
# - No functions from "AnotherModule" will be used outside of "MyModule"
include(AnotherModule)
# Define my function
function(my_module_function)
# Call a function from the other module
another_module_function()
endfunction()
Is there any way inside MyModule.cmake that I can import the functions from AnotherModule.cmake without having them be visible outside of my own module? This other module is written by someone else so I don't have control over it and it includes other functions with very generic names like one called parse_arguments that could potentially cause naming conflicts later on.
Making the functions from AnotherModule.cmake fully invisible outside of MyModule.cmake would be ideal, but even if there were a simple way to just simulate a namespace for the imported functions to be in that would be better than nothing.
In CMake macros and functions has global visibility and nothing can change that.
Often a function, "internal" to some module, is defined with underscore (_) prefix. Such prefix plays the role of a signal to outer code "not to use me". But this is only a convention, CMake doesn't enforce anything about underscore-prefixed names.
If including a module has only immediate effects, that is defines custom commands/targets but does not export functions/macros/variables for outer code, you may consider to wrap it with external project (ExternalProject_Add). An external project is a separate CMake project, and none its CMake things like variables or functions are visible outside it.
Goal : Ability, to create a custom rule set, such that, if a groovy script file has duplicate global variables defined in a groovy script, it should disallow such variable declartions in a file.
I understand, this is technically a valid declaration, since, this is basically overriding the global variable. There's a architectural faultline in the design of the system, where in we need to disallow such declarations, else these declarations comes out as runtime detonators. (declaring the variable final is not an option,since it would involve, refactoring hundreds of groovy scripts.)
Please advice, how can I add a custom rule set to avoid duplicate global variable definition in a groovy shell script.
I would like to share data between a plugin and my main function (this is, use it outside the call to the SCIPsolve function). For example, a branching rule sets a certain int variable to 1 and then, after the optimization is done I can go and check wether the variable was changes or not.
I thought I could accomplish this by using the plugin data (e.g. SCIP_BranchruleData) but it can't be accessed from outside the plugin's source file.
How can I do it?
I will appreciate any help.
Rodolfo
An easy solution is to add a getter function to the branchrule which you implement in branch_xyc.c and prototype in branch_xyz.h. Then your code needs to include the header file and you can access the fields in the branchdata.
See also the documentation of branch_allfullstrong.cpp where an external function is defined and you can see how to get the branchdata and branchrule when passing just a SCIP pointer.
I am working on some extensions for Rebol 3 (posix/fann/math).
To avoid global namespace pollution, I am exporting the functions with a simple prefix source identifier. For example: POSIX-FORK for fork, or POSIX-NANOSLEEP for nanosleep.
Is there any better approach or official Rebol naming convention?
That's a pretty standard naming convention for Rebol exports, though they should be lowercase in the code of course. The all uppercase thing is just a naming convention when referring to functions in chat clients or web sites that can't show code like this. You generally don't uppercase any words in Rebol code unless they are used for something else.
However, if you want to avoid global namespace pollution, declare your extension module with the options: [private] header. That will make it so the exports of your module are only imported by modules or scripts that request them explicitly with import or the needs header. This especially goes for modules or extensions that export low-level C-like APIs, which are best only imported by the modules that implement the high-level wrappers. It's good to remember that the module part of the extension is a full Rebol module, and it is often best to put your high-level wrapper code there and not export the C-like functions at all, keeping them for internal use.
An additional trick is that when you are exporting constants or enum values, it is best to put them in an object in your module and export the object instead. That way you don't export to the global namespace and you can protect the words from modification.
Another trick is to not export stuff at all and have people import your module using the import function. Unless you mark your module's words as hidden they will still be available even if they're not exported. This is a little inconvenient in most cases though, so it's better to use a private module instead. You can also export your high-level API and not export your low-level API, so the low-level API is available to import if someone wants to use it.
Check here for a more thorough answer about how modules and extensions are used: How are words bound within a Rebol module?
I'm writing some unit tests in cocoa for a data driven application.
I've got a constants header file which defines a whole heap of variables including paths to the databases etc.
I was wondering if it's possible to get all the classes to use a different set of constants which would link to a testing version of the database etc.
I've tried redefining the constants, but it doesn't take effect globally.
You could instead have a structure that contained all of the constants used and pass it into your objects' constructors. Normally that structure will be whatever values are necessary to run but when you're testing, you would instead pass a structure with the fields initialized to test parameters
I'm know absolutely nothing about objective C though, so I'm not sure if this is possible for you.
You can put all your constants into a singleton object that has read only properties for the constants. Then you can mock the constants object and change the constants.