Why does Perl access to cross-platform packed structs not work with SWIG? - perl

Working from:
Is ignoring __attribute__((packed)) always safe in SWIG interfaces?
Visual C++ equivalent of GCC's __attribute__ ((__packed__))
My .i does:
#define __attribute__(x)
then uses %include to include my cross-platform definition of PACK():
#if defined(SWIG)
#define PACK(...) VA_ARGS
#elif defined(_MSC_VER)
#define PACK(__Decl__) __pragma(pack(push, 1)) __Decl__ __pragma(pack(pop))
#else // GCC
#define PACK(__Decl__) __Decl__ __attribute__ ((packed))
#endif
Then I have code like:
PACK(
typedef struct {
uint8_t something;
uint32_t more;
} ) aName;
With earlier versions of the PACK() macro, I got syntax error from SWIG on the typedef line. Now I get past that but when compiling the SWIG-generated .c file, I have get and set functions that complain aName doesn't exist. The messages are like (edited):
libudr_perl_swig.c: In function '_wrap_aName_set':
libudr_perl_swig.c:2367:20: error: expected identifier or '(' before
'=' token libudr_perl_swig.c: In function '_wrap_aName_get':
libudr_perl_swig.c:2377:3: error: expected expression before 'aName'
SWIG sort of seems to know about my struct -- it creates access functions -- but the doesn't expose them enough that the access functions can find it.
Before I started to make this cross-platform -- when it was still Linux-only with __attribute__ ((packed)) -- it worked in SWIG. And it still works in Linux. So there appears to be something about SWIG's interpretation of PACK() that is flawed.
The old way generated a lot of per-field code like:
XS(_wrap_aName_something_set) {
{
aName *arg1 = (aName *) 0 ;
...
the new way generates a little per-struct code like:
SWIGCLASS_STATIC int _wrap_aName_set(pTHX_ SV* sv, MAGIC * SWIGUNUSEDPARM(mg)) {
MAGIC_PPERL
{
Why should my PACK() (which should be a no-op in SWIG) do that?

Googling "cpp standard variadic macros" leads to http://en.wikipedia.org/wiki/Variadic_macro which notes the expansion of ... is __VA_ARGS__, not VA_ARGS (as I had found somewhere). When I change my macro definition to be:
#if defined(SWIG)
#define PACK(...) __VA_ARGS__
#elif defined(_MSC_VER)
#define PACK(__Decl__) __pragma(pack(push, 1)) __Decl__ __pragma(pack(pop))
#else // GCC
#define PACK(__Decl__) __Decl__ __attribute__ ((packed))
#endif
it works.

Related

How to use macros to replace/inject function calls in OpenCL

I am developing an algorithm using PyOpenCL. To avoid code duplication I am trying to use templating along with C macros to replace function calls, since OpenCL 1.2 does not support function pointers.
I currently have the following macro section in my OpenCL kernel code:
#define LINEAR_FIT_SEARCH_METHOD ${linear_fit_search_method}
#if LINEAR_FIT_SEARCH_METHOD == MIN_MAX_INTENSITY_SEARCH
#define LINEAR_FIT_SEARCH_METHOD_CALL() determineFitUsingMinMaxIntensitySearch(lineIntensities,imgSizeY,linFitParameter,linFitSearchRangeXvalues)
#elif LINEAR_FIT_SEARCH_METHOD == MAX_INCLINE_SEARCH
#define LINEAR_FIT_SEARCH_METHOD_CALL() determineFitUsingInclineSearch(lineIntensities,imgSizeY,linFitParameter,linFitSearchRangeXvalues,inclineRefinementRange)
#endif
In the kernel code I also define the corresponding functions determineFitUsingMinMaxIntensitySearch and determineFitUsingInclineSearch. I am now attempting to use the macro to exchange the function call like this:
__private struct linearFitResultStruct fitResult = LINEAR_FIT_SEARCH_METHOD_CALL();
so that I select the desired call (note: I always only need either one or the other and configuration is done before the program runs (no need for dynamically switching the two)).
Using PyOpenCL templating I now do something like this:
def applyTemplating(self):
tpl = Template(self.kernelString)
if self.positioningMethod == "maximumIntensityIncline":
linear_fit_search_method="MAX_INCLINE_SEARCH"
if self.positioningMethod == "meanIntensityIntercept":
linear_fit_search_method="MIN_MAX_INTENSITY_SEARCH"
rendered_tpl = tpl.render(linear_fit_search_method=linear_fit_search_method)
self.kernelString=str(rendered_tpl)
Where self.kernelString contains the macro above along with the code.
Unfortunately I am getting this error, which I do not understand:
1:455:53: error: implicit declaration of function 'determineFitUsingInclineSearch' is invalid in OpenCL
1:9:41: note: expanded from macro 'LINEAR_FIT_SEARCH_METHOD_CALL'
1:455:41: error: initializing 'struct linearFitResultStruct' with an expression of incompatible type 'int'
1:536:30: error: conflicting types for 'determineFitUsingInclineSearch'
1:455:53: note: previous implicit declaration is here
1:9:41: note: expanded from macro 'LINEAR_FIT_SEARCH_METHOD_CALL'
1:616:41: error: initializing 'struct linearFitResultStruct' with an expression of incompatible type 'int'
I have very little experience with macros so:
Is what I am attempting even possible in this way or do I need to go a different route?
UPDATE 1:
This code runs fine when I set self.positioningMethod = "meanIntensityIntercept" in my unit test, but fails when setting self.positioningMethod = "maximumIntensityIncline" with the error message above. I cannot spot the error at the yet.
UPDATE 2:
I was also inspired by this post, if that helps:
how to compare string in C conditional preprocessor-directives
As you say you have very little experience with macros then I would go for something simple. determineFitUsingMinMaxIntensitySearch and determineFitUsingInclineSearch accept different number of arguments, so this could done this way:
kernel_code = """
#ifdef USE_FUNCTION_A
void function_a(
int x,
int y,
int extra_param,
__global const int* restrict in,
__global int* restrict out
)
{
//...
}
#else
void function_b(
int x,
int y,
__global const int* restrict in,
__global int* restrict out
)
{
//...
}
#endif
__kernel void my_kernel(
int x,
int y,
__global const int* restrict in,
__global int* restrict out
)
{
// ...
#ifdef USE_FUNCTION_A
function_a(x,y,5,in,out);
#else
function_b(x,y,in,out);
#endif
// ...
}
"""
if use_function_a:
prg = cl.Program(ctx, kernel_code).build("-DUSE_FUNCTION_A")
else:
prg = cl.Program(ctx, kernel_code).build("")

C/C++ Is it possible to #undef a serial of macro starting by the same patern?

I'm writing a tool using macros to generate enum. When done, I want to undef all those macros, but I don't know all names yet. Somes will comes later in developement. So I want to make a generic undef like...
#undef ENUM_*
Is that possible ? The macros simplified looks like that:
First...
#define ENUM_VALUE(VALUE) VALUE,
#define ENUM_STRING(STRING) #STRING,
#define ENUM_GENERATE(NAME)\
namespace NAME {\
enum Enum: int { ENUM_##NAME(ENUM_VALUE) };\
const char *Names[] = { ENUM_##NAME(ENUM_STRING) };\
}\
Then for each enum I define...
#define ENUM_MyEnum(VALUE)\
VALUE(Value1)\
VALUE(Value2)\
VALUE(Value3)
ENUM_GENERATE(MyEnum)
It generate a synchronized enum and string table like if I had declared
namespace MyEnum {
enum Enum: int { Value1, Value2, Value3 };
const char *Names[] = { "Value1", "Value2", "Value3" };
}
The only problem is that I end with truck load of macros. Somes I don't know yet, because they will be define later when I new enums will be creted. But all start by ENUM_
Is there a simple way to undef them all ? Thanks
Here is a detailed proposal for the "base macro" idea from comment:
It leaves some defined macros behind, but guarantees that any use is blocked by a single macro not being defined.
I.e. you undef that single one and all attempts to use one of the macros from the group it represents result in a "undefined" error,
or maybe in some defined expansion, which is however sure to annoy the compiler.
// Infrastructure
#define BASE_BASE(ParWhich) BASED_##ParWhich
// Secondary infrastructure, needed for supporting parameterised macros.
#define BASE_NOPAR(ParWhich) BASE_BASE(ParWhich)
#define BASE_ONEPAR(ParWhich, ParOne) BASE_BASE(ParWhich)(ParOne)
// Potentially many macros being defined in a slightly "get-used-to" manner.
#define BASED_A Hello
#define BASED_B(ParWhat) ParWhat
#define BASED_C(ParWord) ParWord
// Example line, to be expanded by prepro with defined macro BASE_BASE.
BASE_NOPAR(A) BASE_ONEPAR(B,PreProcessor) BASE_NOPAR(B)(World.)
// The one line which should lead to compiler errors for any use of one of the macros.
#undef BASE_BASE
// Same example again.
BASE_NOPAR(A) BASE_ONEPAR(B,PreProcessor) BASE_NOPAR(B)(World.)
// Not necessary, just to make sure and to make readable prepro-output.
#define BASE_BASE(ParIgnore) Compiler, please fail here!
// Same example again.
BASE_NOPAR(A) BASE_ONEPAR(B,PreProcessor) BASE_NOPAR(B)(World.)
Using the parameter-free base macro with a parameter in a following pair braces, as done in the example BASE_NOPAR(C)(World.)
should not be done directly in code anywhere; because it would, in my opinion,
turn into maintenance nightmare soon.
I.e. it should be done in a central "core" place as demonstrated otherwise.
Wouldn't want any code written like that.
Output:
>gcc -E -P BaseMacro.c
Hello PreProcessor World.
BASE_BASE(A) BASE_BASE(B)(PreProcessor) BASE_BASE(B)(World.)
Compiler, please fail here! Compiler, please fail here!(PreProcessor) Compiler, please fail here!(World.) Compiler, please fail here!(World.)

C++ - Why do I have to include .cpp file along with/ instead of .h file to acces the value of a global variable in the following case?

I am trying to properly declare and define global variables in separate files and include them in a third file which deals with class declaration.
The three files are:
1) global.h
#ifndef GLOBAL_H_INCLUDED
#define GLOBAL_H_INCLUDED
extern const int marker_num;
extern const int dim;
using namespace std;
#endif // GLOBAL_H_INCLUDED
2) global.cpp
#include <iostream>
#include <cstdio>
#include <cmath>
#include "global.h"
#include "WorldState.h"
#include "Robot.h"
#include "Sensor.h"
#include "Marker.h"
constexpr const int marker_num = 10;
constexpr const int dim = (2 * marker_num) + 3;
3) WorldState.h
#ifndef WORLDSTATE_H
#define WORLDSTATE_H
#include "global.h"
#include "global.cpp"
class WorldState{
public:
WorldState(float a[], float b[dim][dim]);
get_wstate();
protected:
private:
float w_state[];
float covar_matrix[dim][dim];
};
#endif // WORLDSTATE_H
I am using the global variable dim to declare and define a multidimensional array. I have declared dim inside global.h and defined it inside global.cpp. Now, I have a class called WorldState and inside its header, I am using dim. If I comment out #include "global.cpp", it throws the following error:
C:\Users\syamp\Documents\codeblocks\slam\WorldState.h|10|error: array bound is not an integer constant before ']' token
My understanding is that including the .h file includes the corresponding .cpp as well, and that all declarations should be inside .h and all definitions should be inside .cpp. However, it doesn't seem to work in this case.
1) If I decide to include global.cpp file inside WorldState.h, isn't it bad programming practice? I am trying to write a good code not just a code that works.
2) An alternative is to define values of variable(s) dim (and marker_num) inside global.h. Is that good programming practice?
3) I believe there is something that I am missing. Kindly suggest the best method to resolve this issue. I am using codeblocks and C++11. Thanks in advance.
I am using the global variable dim to declare and define a multidimensional array.
When declaring a fixed-length array at compile-time, the value(s) of its dimension(s) must be known to the compiler, but your separation prevents the value of dim from being known to the compiler at all, so dim cannot be used to specify fixed array dimensions. Any code that uses dim will just compile into a reference to it, and then the linker will resolve the references after compilation is done. Just because dim is declared as const does not make it suitable as a compile-time constant. To do that, you must define its value in its declaration, eg:
#ifndef GLOBAL_H_INCLUDED
#define GLOBAL_H_INCLUDED
static constexpr const int marker_num = 10;
static constexpr const int dim = (2 * marker_num);
using namespace std;
#endif // GLOBAL_H_INCLUDED
Otherwise, if you keep dim's declaration and definition in separate files, you will have to dynamically allocate the array at run-time instead of statically at compile-time.
I have declared dim inside global.h and defined it inside global.cpp.
That is fine for values you don't need to use until run-time. That will not work for values you need to use at compile-time.
My understanding is that including the .h file includes the corresponding .cpp as well
That is not even remotely true. The project/makefile brings in the .cpp file when invoking the compiler. The .h file has nothing to do with that.
that all declarations should be inside .h and all definitions should be inside .cpp.
Typically yes, but not always.
If I decide to include global.cpp file inside WorldState.h, isn't it bad programming practice?
Yes.
An alternative is to define values of variable(s) dim (and marker_num) inside global.h. Is that good programming practice?
Yes, if you want to use them where compile-time constants are expected.

Passing primitive data types by reference in Objective C

I have a C++ function which I call from Objective C.I need to pass variables by reference to the C++ function.But I get the following error in xcode - "Expected ';', ',' or ')' before '&' token in foo.h"
Function declaration in "foo.h"
#ifdef __cplusplus
extern "C"
{
#endif
NSString * LLtoUTM(double Lat,double Long,double &UTMNorthing, double &UTMEasting);
#ifdef __cplusplus
}
#endif
Function call in test_viewcontroller.m
double UTM_x;
double UTM_y;
UTMzone = [[NSString alloc] init];
UTMzone = (NSString *) LLtoUTM(latitude,longitude,UTM_y,UTM_x);
Can anyone tell me what is wrong?
Change the file to be test_viewcontroller.mm.
You told it to compile as an Objective-C file, which doesn't understand references. '.mm' means Objective-C++, which can mix the Obj-C and C++ together like what you're attempting to do.
You simply cannot do this in plain Objective-C — because references don't exist in C. They're a C++ feature. So you have to use Objective-C++, which basically means changing your Objective-C files' extensions to ".mm".

How to redefine a macro using its previous definition

Suppose I have the following macro:
#define xxx(x) printf("%s\n",x);
Now in certain files I want to use an "enhanced" version of this macro without changing its name. The new version explores the functionality of the original version and does some more work.
#define xxx(x) do { xxx(x); yyy(x); } while(0)
This of course gives me redefition warning but why I get 'xxx' was not declared in this scope? How should I define it properly?
EDIT: according to this http://gcc.gnu.org/onlinedocs/gcc-3.3.6/cpp/Self_002dReferential-Macros.html it should be possible
Not possible. Macros can use other macros but they are using the definition available at expand time, not definition time. And macros in C and C++ can't be recursive, so the xxx in your new macro isn't expanded and is considered as a function.
Self-referential macros do not work at all:
http://gcc.gnu.org/onlinedocs/cpp/Self_002dReferential-Macros.html#Self_002dReferential-Macros
If you're working on C++ you can obtain the same results with template functions and namespaces:
template <typename T> void xxx( x ) {
printf( "%s\n", x );
}
namespace my_namespace {
template <typename T> void xxx( T x ) {
::xxx(x);
::yyy(x);
}
}
You won't be able to reuse the old definition of the macro, but you can undefine it and make the new definition. Hopefully it isn't too complicated to copy and paste.
#ifdef xxx
#undef xxx
#endif
#define xxx(x) printf("%s\n",x);
My recommendation is defining an xxx2 macro.
#define xxx2(x) do { xxx(x); yyy(x); } while(0);
If we know type of 'x' parameter in the 'xxx' macro, we can redefine macro by using it in a function and then define the 'xxx' macro as this function
Original definition for the 'xxx' macro:
#define xxx(x) printf("xxx %s\n",x);
In a certain file make enhanced version of the 'xxx' macro:
/* before redefining the "xxx" macro use it in function
* that will have enhanced version for "xxx"
*/
static inline void __body_xxx(const char *x)
{
xxx(x);
printf("enhanced version\n");
}
#undef xxx
#define xxx(x) __body_xxx(x)
From: https://gcc.gnu.org/onlinedocs/gcc/Push_002fPop-Macro-Pragmas.html
#define X 1
#pragma push_macro("X")
#undef X
#define X -1
#pragma pop_macro("X")
int x [X];
It is not exactly what you're asking for but it can help.
You can #undef a macro prior to giving it a new definition.
Example:
#ifdef xxx
#undef xxx
#endif
#define xxx(x) whatever
I never heard of (or seen) a recursive macro though. I don't think it is possible.
This answer doesn't answer your question exactly, but I feel like it does a good job at working the way you would intend to use your method (if it was possible).
The idea is for all of your file-specific macros that do actual work to have a unique name (for example LOG_GENERIC and LOG_SPECIFIC), and having the common token (in your case xxx) simply point to the currently appropriate macro.
Plus, using non-standard but widely available #pragma push_macro and #pragma pop_macro we can both modify the common xxx token and restore it to the previous version.
For example, imagine two header files, generic.hpp and specific.hpp, common token here being LOG:
// generic.hpp
#pragma once
#include <cstdio>
#define LOG_GENERIC(x) printf("INFO: " x "\n")
#define LOG LOG_GENERIC
void generic_fn(){LOG("generic");} // prints "INFO: generic\n"
// specific.hpp
#pragma once
#include "generic.hpp"
#define LOG_SPECIFIC(x) do {printf("<SPECIFIC> "); LOG_GENERIC(x);} while (0)
#pragma push_macro("LOG")
#undef LOG
#define LOG LOG_SPECIFIC
void specific_fn(){LOG("specific");} // prints "<SPECIFIC> INFO: specific\n"
#undef LOG
#pragma pop_macro("LOG")
By doing things this way we get the benefits of:
an easy mechanism to modify LOG in a restorable way via #pragma push_macro and #pragma pop_macro
being able to refer to certain LOG_* macros explicitly (LOG_SPECIFIC can use LOG_GENERIC)
we can't refer to LOG inside of LOG_SPECIFIC definition, we have to go through LOG_GENERIC
this is different to your question, but personally I am of the opinion that this is the better design, otherwise you gain the ability to allow macros above the LOG_SPECIFIC definition to affect it, just sounds like the wrong thing to do every time
Link to a github repository with the example above