Thread Subject: C mex: working with integer mxArrays

Dear all,

I'm new to mexs and C, and I'm trying to figure out the best way of working with Matlab data inside C mex functions. For double and logical Matlab data, the answer seems fairly straightforward if I understand correctly. For example:

double *A;
mxLogical *B;

A = mxGetPr(prhs[0]); /*first input is a double*/
B = mxGetPr(prhs[1]); /*second input is a logical*/

*(A+1)=5; /*assign 5 to second entry of A*/
*(B+1)=5; /*assign 5 to second entry of B*/

Now suppose that prhs[2] is of some integer type, e.g. uint32. What is the best way of declaring a pointer to prhs[2]? How do I know whether to use "int", "long int" or "short int"? If I'm not mistaken, sizes of ints vary from system to system.

Thus, I'm looking for an integer equivalent to mxLogical.

Thanks all.

On 6 Jan, 02:19, "Akim " <a...@bbb.ccc> wrote:
> Dear all,
>
> I'm new to mexs and C, and I'm trying to figure out the best way of working with Matlab data inside C mex functions. For double and logical Matlab data, the answer seems fairly straightforward if I understand correctly. For example:
>
> double *A;
> mxLogical *B;
>
> A = mxGetPr(prhs[0]);   /*first input is a double*/
> B = mxGetPr(prhs[1]);   /*second input is a logical*/
>
> *(A+1)=5;               /*assign 5 to second entry of A*/
> *(B+1)=5;               /*assign 5 to second entry of B*/
>
> Now suppose that prhs[2] is of some integer type, e.g. uint32. What is the best way of declaring a pointer to prhs[2]? How do I know whether to use "int", "long int" or "short int"? If I'm not mistaken, sizes of ints vary from system to system.

Yes, they do. You will have to find out what C(++) data type
matches the uint32 type. As far as I know, the C99 standard
defines size-specific types. If you have a complying compiler
you should cast to that type.

C++, on the other hand, have no such size-specific types, so
you will have to look up the documentation of your system and
compiler.

Rune

Rune Allnor <allnor@tele.ntnu.no> wrote in message <b2ccedff-6d98-4192-a15c-89e0dbd887b8@m3g2000yqf.googlegroups.com>...
> On 6 Jan, 02:19, "Akim " <a...@bbb.ccc> wrote:
> > Dear all,
> >
> > I'm new to mexs and C, and I'm trying to figure out the best way of working with Matlab data inside C mex functions. For double and logical Matlab data, the answer seems fairly straightforward if I understand correctly. For example:
> >
> > double *A;
> > mxLogical *B;
> >
> > A = mxGetPr(prhs[0]);   /*first input is a double*/
> > B = mxGetPr(prhs[1]);   /*second input is a logical*/
> >
> > *(A+1)=5;               /*assign 5 to second entry of A*/
> > *(B+1)=5;               /*assign 5 to second entry of B*/
> >
> > Now suppose that prhs[2] is of some integer type, e.g. uint32. What is the best way of declaring a pointer to prhs[2]? How do I know whether to use "int", "long int" or "short int"? If I'm not mistaken, sizes of ints vary from system to system.
>
> Yes, they do. You will have to find out what C(++) data type
> matches the uint32 type. As far as I know, the C99 standard
> defines size-specific types. If you have a complying compiler
> you should cast to that type.
>
> C++, on the other hand, have no such size-specific types, so
> you will have to look up the documentation of your system and
> compiler.
>
> Rune

Thanks Rune -- it seems that I need "stdint.h", but my compiler doesn't support the C99 standard. For now I will opt for the simplest solution: I'll get my arrays as double, and then manually cast each array element to int.

On Jan 5, 6:19 pm, "Akim " <a...@bbb.ccc> wrote:
> Dear all,
>
> I'm new to mexs and C, and I'm trying to figure out the best way of working with Matlab data inside C mex functions. For double and logical Matlab data, the answer seems fairly straightforward if I understand correctly. For example:
>
> double *A;
> mxLogical *B;
>
> A = mxGetPr(prhs[0]);   /*first input is a double*/
> B = mxGetPr(prhs[1]);   /*second input is a logical*/
>
> *(A+1)=5;               /*assign 5 to second entry of A*/
> *(B+1)=5;               /*assign 5 to second entry of B*/
>

The 'prhs' parameter is not meant to be modified, notice the 'const'
before it in the mexFunction signature?. While you can definitely get
around a const declaration and modify prhs inputs, you shouldn't be
doing that if you're new to mex functions and don't understand all the
implications of doing so. Also, why are you assigning '5' to a member
of a logical array? Technically, you shouldn't even assign a 1 or 0 to
a logical array element. For all you know, MATLAB may represent a
boolean 1 and 0 using the strings 'apple' and 'orange' internally.
There is a function to assign a value to a logical mxArray, I think it
is mxSetLogical(), look it up in the documentation.

> Now suppose that prhs[2] is of some integer type, e.g. uint32. What is the best way of declaring a pointer to prhs[2]? How do I know whether to use "int", "long int" or "short int"? If I'm not mistaken, sizes of ints vary from system to system.
>
> Thus, I'm looking for an integer equivalent to mxLogical.
>
> Thanks all.

A 'short' in C/C++ is always 16-bit while a 'long' is 32-bit. The only
exception would be when your platform's smallest data type is say 32-
bit. Then a short would be 32-bit. Similarly, if the platform only
supported 64-bit and larger data types, both shorts and longs would be
64-bit. In mex files, just include tmwtypes.h and use int16_T,
uint16_T, int32_T, uint32_T, real_T etc. The Mathworks will take care
of the rest for you.

HTH,
Ashish.

"Akim " <aaa@bbb.ccc> wrote in message <hi0oe8$g72$1@fred.mathworks.com>...
> Dear all,
>
> I'm new to mexs and C, and I'm trying to figure out the best way of working with Matlab data inside C mex functions. For double and logical Matlab data, the answer seems fairly straightforward if I understand correctly. For example:
>
> double *A;
> mxLogical *B;
>
> A = mxGetPr(prhs[0]); /*first input is a double*/
> B = mxGetPr(prhs[1]); /*second input is a logical*/

That is not correct. mxGetPr returns a double *, so it should only be used for this type. The above assignment converts a double * to a mxLogical *, which C will often let you get away with but is bad form. For other types, use mxGetData, which returns a void *. e.g.,

B = (mxLogical *) mxGetData(prhs[1]);

> *(A+1)=5; /*assign 5 to second entry of A*/
> *(B+1)=5; /*assign 5 to second entry of B*/

mxLogical type is *likely* a char type, but it may be a bool instead. So this assignment may not do what you expect since 5 may be converted to bool type in this case and not retain the value 5.

> Now suppose that prhs[2] is of some integer type, e.g. uint32. What is the best way of declaring a pointer to prhs[2]? How do I know whether to use "int", "long int" or "short int"? If I'm not mistaken, sizes of ints vary from system to system.
>
> Thus, I'm looking for an integer equivalent to mxLogical.

For mxLogical in particular, it is always 1 byte, and in C the char types are always 1 byte also. So you can always use a char type to get at the mxLogical data and have things match up. e.g., the following will always work for a mxLogical prhs[1] variable that has at least 2 elements:

unsigned char *B;
B = (unsigned char *) mxGetData(prhs[1]);
*(B+1)=5;

For other types, if your compiler does not support the C99 integer size types, you can often figure it out at compile time by using the pre-processor to examine the integer limits in the limints.h header file. e.g., suppose you are looking for a 32-bit integer type to use with MATLAB's uint32 type. You could do something like this:

#include <limits.h>
#if UCHAR_MAX == 4294967295
#define MY32BIT unsigned char
#elif USHRT_MAX == 4294967295
#define MY32BIT unsigned short
#elif UINT_MAX == 4294967295
#define MY32BIT unsigned int
#elif ULONG_MAX == 4294967295
#define MY32BIT unsigned long
#else
#define MY32BIT CANT_FIND_32BIT_INT // Will generate a compile error downstream
#endif

And then in your downstream code use MY32BIT as your 32-bit unsigned integer type. There is no guarantee that any of the integer types for a particular processor will have those limits I show above, but if they do then it is very likely they are 32-bit and will match MATLAB's uint32 class. For 32-bit systems, an int is very likely 32-bits.

James Tursa

"James Tursa" <aclassyguy_with_a_k_not_a_c@hotmail.com> wrote in message <hi1eku$irh$1@fred.mathworks.com>...
> "Akim " <aaa@bbb.ccc> wrote in message <hi0oe8$g72$1@fred.mathworks.com>...
> > Dear all,
> >
> > I'm new to mexs and C, and I'm trying to figure out the best way of working with Matlab data inside C mex functions. For double and logical Matlab data, the answer seems fairly straightforward if I understand correctly. For example:
> >
> > double *A;
> > mxLogical *B;
> >
> > A = mxGetPr(prhs[0]); /*first input is a double*/
> > B = mxGetPr(prhs[1]); /*second input is a logical*/
>
> That is not correct. mxGetPr returns a double *, so it should only be used for this type. The above assignment converts a double * to a mxLogical *, which C will often let you get away with but is bad form. For other types, use mxGetData, which returns a void *. e.g.,
>
> B = (mxLogical *) mxGetData(prhs[1]);
>
> > *(A+1)=5; /*assign 5 to second entry of A*/
> > *(B+1)=5; /*assign 5 to second entry of B*/
>
> mxLogical type is *likely* a char type, but it may be a bool instead. So this assignment may not do what you expect since 5 may be converted to bool type in this case and not retain the value 5.
>
> > Now suppose that prhs[2] is of some integer type, e.g. uint32. What is the best way of declaring a pointer to prhs[2]? How do I know whether to use "int", "long int" or "short int"? If I'm not mistaken, sizes of ints vary from system to system.
> >
> > Thus, I'm looking for an integer equivalent to mxLogical.
>
> For mxLogical in particular, it is always 1 byte, and in C the char types are always 1 byte also. So you can always use a char type to get at the mxLogical data and have things match up. e.g., the following will always work for a mxLogical prhs[1] variable that has at least 2 elements:
>
> unsigned char *B;
> B = (unsigned char *) mxGetData(prhs[1]);
> *(B+1)=5;
>
> For other types, if your compiler does not support the C99 integer size types, you can often figure it out at compile time by using the pre-processor to examine the integer limits in the limints.h header file. e.g., suppose you are looking for a 32-bit integer type to use with MATLAB's uint32 type. You could do something like this:
>
> #include <limits.h>
> #if UCHAR_MAX == 4294967295
> #define MY32BIT unsigned char
> #elif USHRT_MAX == 4294967295
> #define MY32BIT unsigned short
> #elif UINT_MAX == 4294967295
> #define MY32BIT unsigned int
> #elif ULONG_MAX == 4294967295
> #define MY32BIT unsigned long
> #else
> #define MY32BIT CANT_FIND_32BIT_INT // Will generate a compile error downstream
> #endif
>
> And then in your downstream code use MY32BIT as your 32-bit unsigned integer type. There is no guarantee that any of the integer types for a particular processor will have those limits I show above, but if they do then it is very likely they are 32-bit and will match MATLAB's uint32 class. For 32-bit systems, an int is very likely 32-bits.
>
> James Tursa

Thanks all. Sorry for my bad illustrative example -- I know not to modify prhs or assign 5 to logical arrays.

Dear James,

Thanks for the tip with mxGetData. So if I understand correctly, an unsigned char pointer and an mxLogical pointer are essentially equivalent. Does it matter which one I use? I'm a little confused because elsewhere you said, "Use mxLogical, since MATLAB has supplied that data type for you to use." ( http://www.mathworks.com/matlabcentral/newsreader/view_thread/159081#400659 ).

Dear Ashish,

> A 'short' in C/C++ is always 16-bit while a 'long' is 32-bit. The only
> exception would be when your platform's smallest data type is say 32-
> bit.

I just cross-checked on two platforms: long is 32-bit on one platform, and 64-bit on the other. Could you clarify?

Dear Akim!

> So if I understand correctly, an unsigned char pointer and an mxLogical pointer are essentially equivalent. Does it matter which one I use?

*Actually* the replied pointers are equal:
double *p1;
mxLogical *p2;
int16_T *p3;
void *p4;
char *p5;

  p1 = mxGetPr(prhs[0]);
  p2 = (mxLogical *) mxGetData(prhs[0]);
  p3 = (int16_T *) mxGetData(prhs[0]);
  p4 = mxGetData(prhs[0]);
  p5 = (char *) mxGetData(prhs[0]);

All pointers point to the same memory location!
*But*:
1. if prhs[0] is a LOGICAL array, [p2] is the most descriptive pointer. Debugging programs is the most challenging work and every method to increase clarity should be used!
2. The following expressions do *not* (all) point to the same memory location:
  p1[1], p2[1], p3[1], p4[1], p5[1]
  p1 +1, p2 + 1, and so on.
The double pointer p1[1] points to the 2nd double of the array, which is the 9th byte.
The mxLogical pointer p2[1] points to the 2nd mxLogical, which is the 2nd byte.

Another tip: the names I've choosen are dull: "p1", "p2"... How much easier would it be, if I'd use "p_double", "p_logical"...

Perhaps this helps, if you are a C beginner. Good luck, Jan

On Jan 6, 2:42 am, "Akim " <a...@bbb.ccc> wrote:
> "James Tursa" <aclassyguy_with_a_k_not_...@hotmail.com> wrote in message <hi1eku$ir...@fred.mathworks.com>...
> > "Akim " <a...@bbb.ccc> wrote in message <hi0oe8$g7...@fred.mathworks.com>...
> > > Dear all,
>
> > > I'm new to mexs and C, and I'm trying to figure out the best way of working with Matlab data inside C mex functions. For double and logical Matlab data, the answer seems fairly straightforward if I understand correctly. For example:
>
> > > double *A;
> > > mxLogical *B;
>
> > > A = mxGetPr(prhs[0]);   /*first input is a double*/
> > > B = mxGetPr(prhs[1]);   /*second input is a logical*/
>
> > That is not correct. mxGetPr returns a double *, so it should only be used for this type. The above assignment converts a double * to a mxLogical *, which C will often let you get away with but is bad form. For other types, use mxGetData, which returns a void *. e.g.,
>
> > B = (mxLogical *) mxGetData(prhs[1]);
>
> > > *(A+1)=5;                     /*assign 5 to second entry of A*/
> > > *(B+1)=5;                     /*assign 5 to second entry of B*/
>
> > mxLogical type is *likely* a char type, but it may be a bool instead. So this assignment may not do what you expect since 5 may be converted to bool type in this case and not retain the value 5.
>
> > > Now suppose that prhs[2] is of some integer type, e.g. uint32. What is the best way of declaring a pointer to prhs[2]? How do I know whether to use "int", "long int" or "short int"? If I'm not mistaken, sizes of ints vary from system to system.
>
> > > Thus, I'm looking for an integer equivalent to mxLogical.
>
> > For mxLogical in particular, it is always 1 byte, and in C the char types are always 1 byte also. So you can always use a char type to get at the mxLogical data and have things match up. e.g., the following will always work for a mxLogical prhs[1] variable that has at least 2 elements:
>
> > unsigned char *B;
> > B = (unsigned char *) mxGetData(prhs[1]);
> > *(B+1)=5;
>
> > For other types, if your compiler does not support the C99 integer size types, you can often figure it out at compile time by using the pre-processor to examine the integer limits in the limints.h header file. e.g., suppose you are looking for a 32-bit integer type to use with MATLAB's uint32 type. You could do something like this:
>
> > #include <limits.h>
> > #if UCHAR_MAX == 4294967295
> > #define MY32BIT unsigned char
> > #elif USHRT_MAX == 4294967295
> > #define MY32BIT unsigned short
> > #elif UINT_MAX == 4294967295
> > #define MY32BIT unsigned int
> > #elif ULONG_MAX == 4294967295
> > #define MY32BIT unsigned long
> > #else
> > #define MY32BIT CANT_FIND_32BIT_INT  // Will generate a compile error downstream
> > #endif
>
> > And then in your downstream code use MY32BIT as your 32-bit unsigned integer type. There is no guarantee that any of the integer types for a particular processor will have those limits I show above, but if they do then it is very likely they are 32-bit and will match MATLAB's uint32 class. For 32-bit systems, an int is very likely 32-bits.
>
> > James Tursa
>
> Thanks all. Sorry for my bad illustrative example -- I know not to modify prhs or assign 5 to logical arrays.
>
> Dear James,
>
> Thanks for the tip with mxGetData. So if I understand correctly, an unsigned char pointer and an mxLogical pointer are essentially equivalent. Does it matter which one I use? I'm a little confused because elsewhere you said, "Use mxLogical, since MATLAB has supplied that data type for you to use." (http://www.mathworks.com/matlabcentral/newsreader/view_thread/159081#...).
>
> Dear Ashish,
>
> > A 'short' in C/C++ is always 16-bit while a 'long' is 32-bit. The only
> > exception would be when your platform's smallest data type is say 32-
> > bit.
>
> I just cross-checked on two platforms: long is 32-bit on one platform, and 64-bit on the other. Could you clarify?

Akim,
I stand corrected. After some googling, I've learned that 32-bit
systems need not necessarily have 32-bit longs. Here's what the C
standard says:

CHAR_BIT (defined in limits.h) is at least 8 bits
short has a least 16 bits
int has at least 16 bits
long has at least 32 bits
and long long has at least 64 bits.

So the requirement is "at least", not "is". Also, char <= short <= int
<= long <= long long, in terms of their sizes. Sorry about giving you
wrong information, I'm really glad you decided to double check that.

http://www.unix.org/whitepapers/64bit.html
That link discusses data type sizes in great detail and also lists the
models used by various platforms.

Anyway, like I said earlier, in mex files just include tmwtypes.h; it
contains typedefs which use the preprocessor very much like the
example James posted.

"Akim " <aaa@bbb.ccc> wrote in message <hi1ltt$588$1@fred.mathworks.com>...
>
> Thanks for the tip with mxGetData. So if I understand correctly, an unsigned char pointer and an mxLogical pointer are essentially equivalent. Does it matter which one I use? I'm a little confused because elsewhere you said, "Use mxLogical, since MATLAB has supplied that data type for you to use." ( http://www.mathworks.com/matlabcentral/newsreader/view_thread/159081#400659 ).

My advice is the same ... if you are using it as logical data then use mxLogical. The reason I gave the unsigned char example was because your example was attempting to use the underlying data as an integer type and assign a value other than 0 or 1 to it.

James Tursa

Praetorian <ashish.sadanandan@gmail.com> wrote in message <29108ba0-2da0-4dc7-b3ee-2d896a253e04@k17g2000yqh.googlegroups.com>...
> Here's what the C
> standard says:
>
> CHAR_BIT (defined in limits.h) is at least 8 bits
> short has a least 16 bits
> int has at least 16 bits
> long has at least 32 bits
> and long long has at least 64 bits.
>
> So the requirement is "at least", not "is". Also, char <= short <= int
> <= long <= long long, in terms of their sizes.

Not to put too fine a point on it, but the standard is written in terms of min values, not min number of bits. e.g., CHAR_MAX must be at least 127, UCHAR_MAX must be at least 255, etc. Of course, you need at least 8 bits to get these values, so it amounts to the same thing that you have written above. Similar comments for the other integer types.

James Tursa

Thanks again for a fruitful discussion.

"Akim " <aaa@bbb.ccc> wrote in message <hi0oe8$g72$1@fred.mathworks.com>...
> Dear all,
>
> I'm new to mexs and C, and I'm trying to figure out the best way of working with Matlab data inside C mex functions. For double and logical Matlab data, the answer seems fairly straightforward if I understand correctly. For example:
>
> double *A;
> mxLogical *B;
>
> A = mxGetPr(prhs[0]); /*first input is a double*/
> B = mxGetPr(prhs[1]); /*second input is a logical*/
>
> *(A+1)=5; /*assign 5 to second entry of A*/
> *(B+1)=5; /*assign 5 to second entry of B*/
>
> Now suppose that prhs[2] is of some integer type, e.g. uint32. What is the best way of declaring a pointer to prhs[2]? How do I know whether to use "int", "long int" or "short int"? If I'm not mistaken, sizes of ints vary from system to system.
>
> Thus, I'm looking for an integer equivalent to mxLogical.
>
> Thanks all.

UPDATE: In fact mex.h is sufficient, and tmwtypes.h is not needed.

The simple answer to my question appears to be:

An integer equivalent to mxLogical has the form int32_T / uint32_T, etc.

"Akim " <aaa@bbb.ccc> wrote in message <hju68j$eof$1@fred.mathworks.com>...
> "Akim " <aaa@bbb.ccc> wrote in message <hi0oe8$g72$1@fred.mathworks.com>...
> > Dear all,
> >
> > I'm new to mexs and C, and I'm trying to figure out the best way of working with Matlab data inside C mex functions. For double and logical Matlab data, the answer seems fairly straightforward if I understand correctly. For example:
> >
> > double *A;
> > mxLogical *B;
> >
> > A = mxGetPr(prhs[0]); /*first input is a double*/
> > B = mxGetPr(prhs[1]); /*second input is a logical*/
> >
> > *(A+1)=5; /*assign 5 to second entry of A*/
> > *(B+1)=5; /*assign 5 to second entry of B*/
> >
> > Now suppose that prhs[2] is of some integer type, e.g. uint32. What is the best way of declaring a pointer to prhs[2]? How do I know whether to use "int", "long int" or "short int"? If I'm not mistaken, sizes of ints vary from system to system.
> >
> > Thus, I'm looking for an integer equivalent to mxLogical.
> >
> > Thanks all.
>
> UPDATE: In fact mex.h is sufficient, and tmwtypes.h is not needed.
>
> The simple answer to my question appears to be:
>
> An integer equivalent to mxLogical has the form int32_T / uint32_T, etc.

No. mxLogical is 8-bit, not 32-bit.

James Tursa

"Akim " <aaa@bbb.ccc> wrote in message <hju68j$eof$1@fred.mathworks.com>...
> "Akim " <aaa@bbb.ccc> wrote in message <hi0oe8$g72$1@fred.mathworks.com>...
> > Dear all,
> >
> > I'm new to mexs and C, and I'm trying to figure out the best way of working with Matlab data inside C mex functions. For double and logical Matlab data, the answer seems fairly straightforward if I understand correctly. For example:
> >
> > double *A;
> > mxLogical *B;
> >
> > A = mxGetPr(prhs[0]); /*first input is a double*/
> > B = mxGetPr(prhs[1]); /*second input is a logical*/
> >
> > *(A+1)=5; /*assign 5 to second entry of A*/
> > *(B+1)=5; /*assign 5 to second entry of B*/
> >
> > Now suppose that prhs[2] is of some integer type, e.g. uint32. What is the best way of declaring a pointer to prhs[2]? How do I know whether to use "int", "long int" or "short int"? If I'm not mistaken, sizes of ints vary from system to system.
> >
> > Thus, I'm looking for an integer equivalent to mxLogical.
> >
> > Thanks all.
>
> UPDATE: In fact mex.h is sufficient, and tmwtypes.h is not needed.
>
> The simple answer to my question appears to be:
>
> An integer equivalent to mxLogical has the form int32_T / uint32_T, etc.


For future reference, here are the mex equivalents for all matlab types. I have tried a couple of these so far, and #include "mex.h" has been sufficient.

http://www.mathworks.com/access/helpdesk/help/toolbox/eml/ug/bqq7e1s.html
("The following translation table shows the MATLAB types supported by the Embedded MATLAB subset, and how Embedded MATLAB infers the generated code types.")

"Akim " <aaa@bbb.ccc> wrote in message <hkqfmt$mr6$1@fred.mathworks.com>...
>
> For future reference, here are the mex equivalents for all matlab types. I have tried a couple of these so far, and #include "mex.h" has been sufficient.
>
> http://www.mathworks.com/access/helpdesk/help/toolbox/eml/ug/bqq7e1s.html
> ("The following translation table shows the MATLAB types supported by the Embedded MATLAB subset, and how Embedded MATLAB infers the generated code types.")

No. As the footnote states, the table is for Embedded MATLAB, *not* mex files. Do not use this table for mex programming. For example, the table lists the MATLAB char type as being equivalent to a C char type. This is not true for mex files. A char type in MATLAB is 2 bytes per character, whereas a char type in C is 1 byte per character. This difference needs to be accounted for in mex files. Also the storage of complex data is different in the Embedded MATLAB table (real and imaginary data interleaved in memory, same as Fortran) from regular MATLAB (real and imaginary data separated in memory).

James Tursa

"James Tursa" <aclassyguy_with_a_k_not_a_c@hotmail.com> wrote in message <hkqhd9$87j$1@fred.mathworks.com>...
> "Akim " <aaa@bbb.ccc> wrote in message <hkqfmt$mr6$1@fred.mathworks.com>...
> >
> > For future reference, here are the mex equivalents for all matlab types. I have tried a couple of these so far, and #include "mex.h" has been sufficient.
> >
> > http://www.mathworks.com/access/helpdesk/help/toolbox/eml/ug/bqq7e1s.html
> > ("The following translation table shows the MATLAB types supported by the Embedded MATLAB subset, and how Embedded MATLAB infers the generated code types.")
>

Dear James,

> For example, the table lists the MATLAB char type as being equivalent to a C char type. This is not true for mex files.

Leaving char aside, nonetheless the following seem to match, no?

MATLAB C Type C Reference Type
int8 int8_T int8_T *
int16 int16_T int16_T *
int32 int32_T int32_T *
uint8 uint8_T uint8_T *
uint16 uint16_T uint16_T *
uint32 uint32_T uint32_T *
double real_T real_T *
single real32_T real32_T *

If the above do match, why not use the table for ints, single and double?

Regards.

"Akim " <aaa@bbb.ccc> wrote in message <hkqlat$8jf$1@fred.mathworks.com>...
> "James Tursa" <aclassyguy_with_a_k_not_a_c@hotmail.com> wrote in message <hkqhd9$87j$1@fred.mathworks.com>...
> > "Akim " <aaa@bbb.ccc> wrote in message <hkqfmt$mr6$1@fred.mathworks.com>...
> > >
> > > For future reference, here are the mex equivalents for all matlab types. I have tried a couple of these so far, and #include "mex.h" has been sufficient.
> > >
> > > http://www.mathworks.com/access/helpdesk/help/toolbox/eml/ug/bqq7e1s.html
> > > ("The following translation table shows the MATLAB types supported by the Embedded MATLAB subset, and how Embedded MATLAB infers the generated code types.")
> >
>
> Dear James,
>
> > For example, the table lists the MATLAB char type as being equivalent to a C char type. This is not true for mex files.
>
> Leaving char aside, nonetheless the following seem to match, no?
>
> MATLAB C Type C Reference Type
> int8 int8_T int8_T *
> int16 int16_T int16_T *
> int32 int32_T int32_T *
> uint8 uint8_T uint8_T *
> uint16 uint16_T uint16_T *
> uint32 uint32_T uint32_T *
> double real_T real_T *
> single real32_T real32_T *
>
> If the above do match, why not use the table for ints, single and double?
>
> Regards.

For those particular types, as long as your compiler supports the xxx_T types (not all compilers do), then yes, go ahead and use them.

James Tursa