Reading hideously-long argument lists
Dear Lazyweb,
In a C++ function with C linkage, are the arguments stored in a predictable way such that, e.g., I could cast the location of the first argument to a pointer to a struct containing the argument list?
Background
There is a commercial finite element package, ABAQUS, which has the nice feature of letting you programmatically define arbitrary materials. You just provide it with an object file containing the function umat_.
Unfortunately, since this interface was designed by Fortran programmers a while ago, umat_ takes 38 arguments, many of which are two-dimensional arrays. Since it is the year 2007 and some languages actually provide meaningful abstraction, I quickly made a umat_arguments class so my umat_ function just calls a C++ function, int umat(umat_arguments& in). Of course, I have to construct the umat_arguments structure which means copy-paste coding - exactly what I'm trying to avoid.
While the huge argument list is dirty, it is nice that ABAQUS has presumably put a lot more thought than I want to into exactly what a finite-element package would need to ask of a material point to be completely general.
In a C++ function with C linkage, are the arguments stored in a predictable way such that, e.g., I could cast the location of the first argument to a pointer to a struct containing the argument list?
Background
There is a commercial finite element package, ABAQUS, which has the nice feature of letting you programmatically define arbitrary materials. You just provide it with an object file containing the function umat_.
Unfortunately, since this interface was designed by Fortran programmers a while ago, umat_ takes 38 arguments, many of which are two-dimensional arrays. Since it is the year 2007 and some languages actually provide meaningful abstraction, I quickly made a umat_arguments class so my umat_ function just calls a C++ function, int umat(umat_arguments& in). Of course, I have to construct the umat_arguments structure which means copy-paste coding - exactly what I'm trying to avoid.
While the huge argument list is dirty, it is nice that ABAQUS has presumably put a lot more thought than I want to into exactly what a finite-element package would need to ask of a material point to be completely general.