I am trying to integrate a model that I designed in Simulink to work in my S-function (C-code). For this I used the Simulink Code generation (System target file: err.tlc) to build C-Code.
I am am doing it in this seemingly overly complex way because my main s-function is realizing a evolutionary algorithm and this Simulink model is how it evaluates each individual. (hope that makes sense).
So I just generated the C-code and am now trying to implement it in this S-function c-code.
As I am fairly new to this is used the generated ert_main.c as a reference.
#include <stdio.h> /* This ert_main.c example uses printf/fflush */
#include "Peltier_model.h" /* Model's header file */
#include "rtwtypes.h"
#include "builtin_typeid_types.h"
#include "multiword_types.h"
#include "rt_logging.h"
#define QUOTE1(name) #name
#define QUOTE(name) QUOTE1(name) /* need to expand name */
#ifndef SAVEFILE
# define MATFILE2(file) #file ".mat"
# define MATFILE1(file) MATFILE2(file)
# define MATFILE MATFILE1(MODEL)
#else
# define MATFILE QUOTE(SAVEFILE)
#endif
this part I copied to the header file of my own C-code.
When I trie to mex it I first had the problem that it could not find rt_logging.h, so I included the following path in mex:
mex -I/Applications/MATLAB_R2013b.app/rtw/c/src ....
That solved that part.
The problem now is that my included Peltier_model.h (generated code) includes rt_logging.h which includes rt_mxclassid.h (all of which chi with Matlab and i didn't touch) which then creates a redefinition error:
In file included from Peltier_model_ert_rtw/Peltier_model.h:28:
In file included from /Applications/MATLAB_R2013b.app/rtw/c/src/rt_logging.h:19:
/Applications/MATLAB_R2013b.app/rtw/c/src/rt_mxclassid.h:18:2: error: redefinition of enumerator 'mxLOGICAL_CLASS'
mxLOGICAL_CLASS,
^
/Applications/MATLAB_R2013b.app/extern/include/matrix.h:287:5: note: previous definition is here
mxLOGICAL_CLASS,
^
So I have a problem with the redefinition of enumerates (from within rt_mxclassid.h) previously defined in matrix.h.
The same happens for the other enumerates defined in that part of the matrix.h
rt_classid.h:
/* $Revision: 1.1.6.1 $ */
#ifndef __rt_mxclassid_h__
#define __rt_mxclassid_h__
typedef enum {
mxUNKNOWN_CLASS = 0,
mxCELL_CLASS = 1,
mxSTRUCT_CLASS,
mxLOGICAL_CLASS,
mxCHAR_CLASS,
mxRESERVED5_CLASS, /* mxVOID_CLASS */
mxDOUBLE_CLASS,
mxSINGLE_CLASS,
mxINT8_CLASS,
mxUINT8_CLASS,
mxINT16_CLASS,
mxUINT16_CLASS,
mxINT32_CLASS,
mxUINT32_CLASS,
mxINT64_CLASS, /* place holder - future enhancements */
mxUINT64_CLASS, /* place holder - future enhancements */
mxRESERVED16_CLASS, /* mxFUNCTION_CLASS */
mxRESERVED17_CLASS, /* mxOPAQUE_CLASS */
mxOBJECT_CLASS
} mxClassID;
#endif /* __rt_mxclassid_h__ */
relevant part of matrix.h:
/**
* Enumeration corresponding to all the valid mxArray types.
*/
typedef enum
{
mxUNKNOWN_CLASS = 0,
mxCELL_CLASS,
mxSTRUCT_CLASS,
mxLOGICAL_CLASS,
mxCHAR_CLASS,
mxVOID_CLASS,
mxDOUBLE_CLASS,
mxSINGLE_CLASS,
mxINT8_CLASS,
mxUINT8_CLASS,
mxINT16_CLASS,
mxUINT16_CLASS,
mxINT32_CLASS,
mxUINT32_CLASS,
mxINT64_CLASS,
mxUINT64_CLASS,
mxFUNCTION_CLASS,
mxOPAQUE_CLASS,
mxOBJECT_CLASS, /* keep the last real item in the list */
#if defined(_LP64) || defined(_WIN64)
mxINDEX_CLASS = mxUINT64_CLASS,
#else
mxINDEX_CLASS = mxUINT32_CLASS,
#endif
/* TEMPORARY AND NASTY HACK UNTIL mxSPARSE_CLASS IS COMPLETELY ELIMINATED */
mxSPARSE_CLASS = mxVOID_CLASS /* OBSOLETE! DO NOT USE */
}
mxClassID;
I am quite lost how to deal with this since any of the problematic files are written by me. Any Help would be much appreciated !!
Thanks a lot !
Related
For context, I'm writing an operating system:
I have a struct vt_device_s and a struct __vt_device_s which is architecture specific and lives inside of vt_device_s like so:
struct
vt_device_s
{
struct __vt_device_s __device;
size_t cursor_x;
size_t cursor_y;
};
Now for the architectural struct:
struct
__vt_device_s
{
uint16_t *memory;
size_t memory_len;
};
The header <dev/vt.h> knows about __vt_device_s defined in <sys/_vt.h> because it is included, yet I get this error:
error: field '__device' has incomplete type
48 | struct __vt_device_s __device;
|
I realise this is because both files rely on each other (the whole conflict is caused by _vt.c including _vt.h including vt.h including _vt.h) but I don't understand how it is a compile problem. I have include guards in both files!
PS: I understand this would be a non-issue if I used a pointer but as it's an operating system, this driver needs to function before paging is set up (that is, malloc and free don't exist yet).
Here are the three files in question:
dev/vt.h
#ifndef _DEV_VT_H_
#define _DEV_VT_H_ 1
#include <stddef.h>
#include <sys/_vt.h>
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
struct
vt_device_s
{
struct __vt_device_s __device;
size_t cursor_x;
size_t cursor_y;
};
void vt_init(struct vt_device_s *);
#ifdef __cplusplus
}
#endif /* __cplusplus */
#endif /* _DEV_VT_H_ */
sys/_vt.h
#ifndef _I386__VT_H_
#define _I386__VT_H_ 1
#include <stddef.h>
#include <stdint.h>
#include <dev/vt.h>
#define __VT_WIDTH 80
#define __VT_HEIGHT 25
#define __VT_MEMOFF 0xb8000
#ifdef __cplusplus
extern "C" {
#endif /* __cplusplus */
struct
__vt_device_s
{
uint16_t *memory;
size_t memory_len;
};
void __vt_init(struct vt_device_s *);
#ifdef __cplusplus
}
#endif /* __cplusplus */
#endif /* _I386__VT_H_ */
sys/_vt.c
#include <sys/_vt.h>
void
__vt_init(struct vt_device_s *device)
{
device->__device.memory = (uint16_t *) __VT_MEMOFF;
device->__device.memory_len = __VT_WIDTH * __VT_HEIGHT;
}
Your double include guards prevent the one file from including itself when it is re-included by the other. The only way to fix this is you have got to break the cycle. Decide which header is "higher" and will include the "lower" and don't try to include the higher one from the lower one. The lower one must be valid on its own.
The reason for this is that the pre-processor has to transform multiple files into one linear sequence of lines for the compiler. The compiler has to see one set of file contents before the other.
If you have cyclic includes like this you make it up to the final user of the code which one comes first. If they include file A, then it will include file B, which will try to include file A again but it will be prevented by the include guards, so the contents of B will be parsed first. On the other hand if the final user includes B first, then the contents of A will be seen first by the compiler.
So if you leave it like it is, then it is effectively random which file gets included first. If you break the cycle, you get to decide yourself which is included first.
Once you have decided, you can fix the compiler errors about incomplete types by making whichever file you choose to put first able to stand on its own and then letting the one that is second use definitions from the first.
In my model I have quite some parameters that are used by a lot of different functions.
To make changing settings easy, I want to use one file for all my paramaters, keeping it sepperate from any of the "real programming".
That file is called parameters.c
In it, all parameters are defined like:
#define N 1000
#define T 1373
In a different c file (MyLib.c), I create a struct type:
typedef struct Model{
struct Element el[N];
};
both files are included in my main script using:
#include "parameters.c"
#include "MyLib.c"
The project can not be build this way. However, if I move the line
#define N 1000
from parameters.c to MyLib.c, it works.
I could just create the struct to have an array that is larger than any N value I'd use, but that doesn't seem like the correct way to do it.
Is there a correct way to implement this, or would I indeed have to create the large array? (in the comments it was said the definition of correct is too broad. In this instance I mean memory efficient. I don't want to allocate a much larger chunck of memory than I need to.)
Thanks in advance.
Is there a correct way to implement this
You library may look like this:
// parameters.h
#ifndef PARAMETERS_H_
#define PARAMETERS_H_
// documentation
#define PARAMETERS_COUNT_OF_ELEMENTS 1000
// this parameters does that and that
#define PARAMETERS_DESCRIPTIVE_NAME 1373
// ^^^^^^^^^^^ - consistent namespace naming
#endif
// mylib.h - safe yourself trouble and DoN'T mIx UppErCaSe with lOwErcAsE
// escapecially in header names
// subjectively, I do not like pascal case - snake case rule them all!
#ifndef MYLIB_H_
#define MYLIB_H_
#include "parameters.h"
#include "element.h" // for struct element
/// This structure represents a model in our library.
struct mylib_model {
// ^^^^^^ - consistent namespace naming
/// These are super important elements we deeply care about.
struct element el[PARAMETERS_COUNT_OF_ELEMENTS];
};
/**
* #brief this function does that and that
* #return 0 on success, otherwise error
*
* Write documentation keeping consistent style, for example
* use doxygen.
*/
int mylib_do_something(struct mylib_model *the_model);
#endif
// mylib.c
#include "mylib.h"
int mylib_do_something(struct mylib_model *t) {
// do something here
// return 0 on success, otherwise document error codes, or use the ones from errno.h
return 0;
}
// main.c
#include "mylib.h"
int main() {
struct mylib_model model = {0};
int err = mylib_do_something(&model);
if (err != 0) { abort(); }
return 0;
}
Your parmeters.h is very similar to the way autoconf projects generate config.h present in many GNU projects. Many projects use a configuration file, sometimes generate automatically by a build system. Nowadays if choosing build automation software I would recommend cmake. Other links: kernel coding style and google coding style.
I added "Mersenne Twist Pseudorandom Number Generator Package" (one header file and one source file) to my Clion C project, but I can not build the project.
the error is :
multiple definition of `mts_lrand'
I can successfully compile and run the program using just command line and gcc but in Clion i can not.
I think it has something to do with macros, but I do not know how to fix it.
here is some part of the code i added:
mtwist.h
.
.
.
.
/*
* In gcc, inline functions must be declared extern or they'll produce
* assembly code (and thus linking errors). We have to work around
* that difficulty with the MT_EXTERN define.
*/
#ifndef MT_EXTERN
#ifdef __cplusplus
#define MT_EXTERN /* C++ doesn't need static */
#else /* __cplusplus */
#define MT_EXTERN extern /* C (at least gcc) needs extern */
#endif /* __cplusplus */
#endif /* MT_EXTERN */
/*
* Make it possible for mtwist.c to disable the inline keyword. We
* use our own keyword so that we don't interfere with inlining in
* C/C++ header files, above.
*/
#ifndef MT_INLINE
#define MT_INLINE inline /* Compiler has inlining */
#endif /* MT_INLINE */
/*
* Try to guess whether the compiler is one (like gcc) that requires
* inline code to be available in the header file, or a smarter one
* that gets inlines directly from object files. But if we've been
* given the information, trust it.
*/
#ifndef MT_GENERATE_CODE_IN_HEADER
#ifdef __GNUC__
#define MT_GENERATE_CODE_IN_HEADER 1
#endif /* __GNUC__ */
#if defined(__INTEL_COMPILER) || defined(_MSC_VER)
#define MT_GENERATE_CODE_IN_HEADER 0
#endif /* __INTEL_COMPILER || _MSC_VER */
#endif /* MT_GENERATE_CODE_IN_HEADER */
#if MT_GENERATE_CODE_IN_HEADER
/*
* Generate a random number in the range 0 to 2^32-1, inclusive, working
* from a given state vector.
*
* The generator is optimized for speed. The primary optimization is that
* the pseudorandom numbers are generated in batches of MT_STATE_SIZE. This
* saves the cost of a modulus operation in the critical path.
*/
MT_EXTERN MT_INLINE uint32_t mts_lrand(
register mt_state* state) /* State for the PRNG */
{
register uint32_t random_value; /* Pseudorandom value generated */
if (state->stateptr <= 0)
mts_refresh(state);
random_value = state->statevec[--state->stateptr];
MT_PRE_TEMPER(random_value);
return MT_FINAL_TEMPER(random_value);
}
.
.
.
.
you see the function definition is in header file, i think this is the problem but I don't know what to do
you can see complete code here.
Please,
could you tell me what does the code below do?
...code...
#include file.h
...code...
I was used to put includes a the beggining of each file. I have never seen this before and also wasn't able to find anything in the internet.
#include is a pre-processor directive that takes the file given as the argument and dumps its contents in the current file. Typically, this is used to include definitions of commons functions from header files, but there's no necessity to use it in that way.
It's usage is not limited to the starting of the file, but note that the variables, macros or functions declared in this header will not be usable before the include statement even if on the same file.
As everyone tells you #include can be used every where (provided it is on its own logicial line). And there are cases where you want to #include several times the same file. Read first the X macro wikipage, and the C preprocessor wikipage.
And I have a concrete example in my MELT monitor (related to MELT ...).
I have a predef-monimelt.h (generated) file containing lines like
MOM_PREDEFINED_NAMED( name, id,hash) e.g.
MOM_PREDEFINED_NAMED(GET,_9dsak0qcy0v_1c5z9th7x3i,1573018885)
MOM_PREDEFINED_NAMED(HEAD,_47fatww79x6_vh8ap22c0ch,3922245622)
MOM_PREDEFINED_NAMED(web_handler,_7sav6zery1v_24sa6jwwu6c,2339220870)
#undef MOM_PREDEFINED_NAMED
My monimelt.h file (a real header file) define external pointers and an enum, so has notably:
// declare the predefined
#define MOM_PREDEFINED_NAMED(Name,Id,H) extern momitem_t* mom_named__##Name;
#include "predef-monimelt.h"
/// declare the hash of the predefined as an enum
#define MOM_PREDEFINED_NAMED(Name,Id,H) mom_hashname__##Name = H,
enum {
#include "predef-monimelt.h"
};
My main.c file contains notably a routine :
// if this routine is compiled, we are sure that all predefined hashes
// are unique
const momitem_t *
mom_predefined_item_of_hashcode (momhash_t h) {
switch (h) {
#define MOM_PREDEFINED_NAMED(Nam,Id,Hash) case Hash: return mom_named__##Nam;
#include "predef-monimelt.h"
default:
return NULL;
}
}
but my items.c includes the predef-monimelt.h file twice (to create the predefined items at initialization, and to define their variables):
void mom_create_predefined_items (void) {
int nbnamed = 0;
#define MOM_PREDEFINED_NAMED(Nam,Id,H) do { \
mom_named__##Nam = mom_make_item_of_identcstr(#Id); \
mom_named__##Nam->i_space = momspa_predefined; \
mom_register_item_named_cstr (mom_named__##Nam, #Nam); \
nbnamed ++; \
} while(0);
#include "predef-monimelt.h"
} // end of mom_create_predefined_items
// declare the predefined
#define MOM_PREDEFINED_NAMED(Nam,Id,H) momitem_t* mom_named__##Nam;
#include "predef-monimelt.h"
FWIW, the MELT monitor is GPLv3+ licensed software
I'm just getting started with modular programming in C. I think I'm doing something wrong with the inclusions, because I'm getting a lot of conflicting types for 'functionName' and previous declaration of 'functionName' was here errors. I did put inclusion guards in place.
Do you know a clear tutorial that explains modular programming in C, especially how the inclusions work?
Update: I have tried to isolate my issue. Here's some code, as requested.
Update 2: updated code is below. The errors have been updated, too.
/*
* main.c
*/
#include <stdio.h>
#include "aStruct.h"
int main() {
aStruct asTest = createStruct();
return 0;
}
/*
* aStruct.h
*/
#ifndef ASTRUCT_H_
#define ASTRUCT_H_
struct aStruct {
int value1;
int value2;
struct smallerStruct ssTest;
};
typedef struct aStruct aStruct;
aStruct createStruct();
#endif /* ASTRUCT_H_ */
/*
* smallerStruct.h
*/
#ifndef SMALLERSTRUCT_H_
#define SMALLERSTRUCT_H_
struct smallerStruct {
int value3;
};
typedef struct smallerStruct smallerStruct;
smallerStruct createSmallerStruct();
#endif /* SMALLERSTRUCT_H_ */
/*
* aStruct.c
*/
#include <stdio.h>
#include "smallerStruct.h"
#include "aStruct.h"
aStruct createStruct() {
aStruct asOutput;
printf("This makes sure that this code depends on stdio.h, just to make sure I know where the inclusion directive should go (main.c or aStruct.c).\n");
asOutput.value1 = 5;
asOutput.value2 = 5;
asOutput.ssTest = createSmallerStruct();
return asOutput;
}
/*
* smallerStruct.c
*/
#include <stdio.h>
#include "smallerStruct.h"
smallerStruct createSmallerStruct() {
smallerStruct ssOutput;
ssOutput.value3 = 41;
return ssOutput;
}
This generates the following error messages:
At aStruct.h:10
field 'ssTest' has incomplete type
At main.c:8
unused variable `asTest' (this one makes sense)
The base of inclusion is to make sure that your headers are included only once. This is usually performed with a sequence like this one:
/* header.h */
#ifndef header_h_
#define header_h_
/* Your code here ... */
#endif /* header_h_ */
The second point is to take care of possible name conflicts by handling manually pseudo namespaces with prefixes.
Then put in your headers only function declarations of public API. This may imply to add typedefs and enums. Avoid as much as possible to include constant and variable declarations: prefer accessor functions.
Another rule is to never include .c files, only .h. This is the very point of modularity: a given module dependant of another module needs only to know its interface, not its implementation.
A for your specific problem, aStruct.h uses struct smallerStruct but knows nothing about it, in particular its size for being able to allocate an aStruct variable. aStruct.h needs to include smallerStruct.h. Including smallerStruct.h before aStruct.h in main.c doesn't solve the issue when compiling aStruct.c.
The multiple definition problem is most likely coming from the way you're including the code. You are using #include "aStruct.c" as opposed to #include "aStruct.h". I suspect you are also compiling the .c files into your project in addition to the #include. This causes the compiler to become confused due to the multiple definitions of the same function.
If you change the #include to #include "aStruct.h" and make sure the three source files are compiled and linked together, the error should go away.
Such errors mean that function declaration (return type or parameter count/types) differs from other function declarations or function definition.
previous declaration message points you to the conflicting declaration.